mariateixeira-EC - Engenharia de Software - Conteúdo 3.2011.2

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software
Disciplina: Engenharia de Software Pgina: 29
3 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

mais fcil escrever um programa incorreto do que entender um correto. [Alan Perlis] Um processo define quem est fazendo o qu, quando e como para alcanar um certo objetivo. [Ivar Jacobson, Grady Booch e James Rumbaugh] Se o processo for fraco, o produto final sofrer inevitavelmente, mas uma nfase exagerada no processo tambm perigosa. [Roger Pressman, 2006]
3.1 PANORAMA SOBRE PROCESSO DE SOFTWARE

Origem: Engenharia de Software, Roger Pressman, 2006
O que ? Quando voc elabora um produto ou sistema importante percorrer uma srie de passos previsveis um roteiro que o ajuda a criar a tempo um resultado de alta qualidade. O roteiro que voc segue chamado de Processo de Software; Quem faz? Os engenheiros de software e seus gerentes adaptam o processo a suas necessidades e depois o seguem. Alm disso, o pessoal que solicitou o software tem um papel a desempenhar no processo de defin-lo, constru-lo e test-lo; Por que importante? Porque fornece estabilidade, controle e organizao para uma atividade que pode, se deixada sem controle, tornar-se bastante catica. No entanto, uma abordagem moderna de engenharia de software precisa ser gil. Precisa exigir apenas aquelas atividades, controles e documentao adequados equipe de projeto e ao produto que deve ser produzido; Quais so os passos? Em nvel de detalhe, o processo adotado depende do software que voc est construindo. Um processo poderia ser apropriado criao de softwares para o sistema de avinica de uma aeronave, enquanto um processo inteiramente diferente seria indicado para a criao de um site; Qual o produto do trabalho? Do ponto de vista de um engenheiro de software, os produtos do trabalho so os programas, documentos e dados produzidos em consequncia das atividades e tarefas definidas pelo processo; Como tenho certeza de que fiz corretamente? Existem diversos mecanismos de avaliao do processo de software que permitem s organizaes determinar a maturidade do seu processo de software. Todavia, a qualidade, pontualidade e viabilidade a longo prazo do produto que voc constri so os melhores indicadores da eficcia do processo usado.
3.2 O QUE PROCESSO?

Sobre o Processo de Software, Shari L. Pfleeger (2004) destaca os seguintes itens: Conjunto de tarefas ordenadas; Uma srie de etapas que envolvem atividades, restries e recursos para alcanar a sada desejada; Quando envolve a elaborao de um produto, podemos chamar de Ciclo de Vida;
Descreve a vida do produto de software desde a concepo at a implementao, entrega, utilizao e manuteno.
H autores que defendem, no entanto, que o ciclo de vida uma parte de um processo de desenvolvimento de software, focado nas atividades e na sequncia em que elas devem ser executadas. E que o processo apresenta outros itens, como ferramentas e pessoal envolvido. Considerando a farta variedade de problemas que podem ser resolvidos atravs da elaborao de um software, diferentes processos de desenvolvimento podem ser aplicados. Para contemplar essa situao, diferentes Modelos de Processo de Desenvolvimento de Software esto disponveis na literatura, servindo como base para que uma organizao elabore o seu prprio modelo, mais adequado s suas caractersticas individuais.
3.3 ATIVIDADES TPICAS DO PROCESSO DE SOFTWARE

Diferentes autores consideram diferentes atividades como sendo bsicas para a definio de um processo. Porm, mesmo que se considerem diferentes nomeclaturas e divises, elas contm essencialmente a mesma idia, quando consideradas em conjunto. Um exemplo bastante comum, de grupo de atividades bsicas o seguinte: Desenvolvimento Anlise, Design e Implementao. As funcionalidades e as restries so especificadas e o software produzido; Validao & Verificao O software testado. Observao: Verificao x Validao. Verificao Checar se realizou todas as atividades (Fazendo certo a coisa). Validao Checar se o artefato est correto (Fazendo a coisa certa); Manuteno O software sofre correes, adaptaes e ampliaes.
J Pressman (2006) destaca o seguinte conjunto de atividades genricas de um processo: Comunicao Essa atividade envolve alta comunicao e colaborao com o cliente (e outros stakeholders) e abrange o levantamento de requisitos e outras atividades relacionadas; Planejamento Essa atividade estabelece um plano para o trabalho de engenharia de software. Descreve as tarefas tcnicas a serem conduzidas, os riscos provveis, os recursos que sero necessrios, os produtos de trabalho a serem produzidos e um cronograma de trabalho; Modelagem Essa atividade inclui a criao de modelos que permitam ao desenvolvedor e ao cliente, entender melhor os requisitos do software e o projeto que vai satisfazer a esses requisitos; Construo Essa atividade combina gerao de cdigo (manual ou automtica) e os testes necessrios para revelar erros no cdigo; Implantao O software entregue ao cliente, que avalia o produto e fornece feedback.
Pressman (2006) complementa que as atividades genricas so complementadas por uma srie de atividades guarda-chuva, entre as quais podem ser citadas: Acompanhamento e controle de projeto de software; Gesto de risco; Garantia de qualidade de software; Revises tcnicas formais; Medio; Gesto de configurao de software; Gesto de reusabilidade; Preparao e produo do produto do trabalho.
O mesmo autor ainda comenta o seguinte: Toda organizao de Engenharia de software deveria descrever um conjunto especfico de atividades de arcabouo para o(s) processo(s) de software que adota. Deveria preencher cada atividade de arcabouo com um conjunto de aes de engenharia de software e definir cada ao em termos de um conjunto de tarefas que identifique o trabalho (e produtos de trabalho) a ser realizado para satisfazer s metas de desenvolvimento. Deveria, ento, adaptar o modelo de processo resultante para acomodar a natureza especfica de cada projeto, o pessoal que vai fazer o trabalho e o ambiente no qual o trabalho vai ser conduzido. Independentemente do modelo de processo que seja selecionado, os engenheiros de software tem tradicionalmente escolhido um arcabouo de processo genrico que inclui as seguintes atividades de arcabouo: comunicao, planejamento, modelagem, construo e implantao.
3.4 CICLO DE VIDA DE SOFTWARE

Como todo produto industrial o software tem um ciclo de vida: Ele concebido a partir da percepo de uma necessidade; desenvolvido, transformando-se em um conjunto de itens entregue a um cliente; Entra em operao, sendo usado dentro de algum processo de negcio e sujeito a atividades de manuteno, quando necessrio; retirado de operao ao final de sua vida til.
Assim pode-se fazer a seguinte definio para Ciclo de Vida: O ciclo de vida do software uma sequncia de diferentes atividades executadas ao longo da existncia do software. Cada fase do ciclo de vida tem divises e subdivises. interessante destacar que a fase de codificao, que representa a escrita final de um programa em forma inteligvel para um computador, apenas uma pequena parte do ciclo de vida. Para a maioria das pessoas, inclusive muitos profissionais, essa ainda parece ser a nica tarefa de um produtor de software. Segue abaixo um esquema simplificado de Ciclo de Vida de Software.
Percepo da Necessidade Concepo Elaborao Desenho Arquitetnico Desenho detalhado Construo Liberao Codificao Teste De Unidade Testes de Aceitao Transio Operao Retirada
Ciclo de Vida
Desenvolvimento
Assim, pode-se dizer que o ciclo de vida bsico do software: Comea na concepo do problema; Termina quando o sistema sai de uso.
A seguir est disponibilizada uma lista das atividades mais comumente realizadas durante o ciclo de vida de um software. Estudo de Viabilidade: Determina se o desenvolvimento proposto vivel; Anlise de Mercado: Determina se existe mercado potencial para o produto; Levantamento de Requisitos: Determina quais funcionalidades o software deve ter; Elicidao dos Requisitos: Obtm os requisitos do usurio; Anlise de Domnio: Identifica e caracteriza o ambiente (domnio) no qual est o problema que o software pretende solucionar;
Planejamento de Projeto: Determina como desenvolver o software; Anlise de Custos: Determina a estimativa dos custos; Elaborao de Cronograma: Identifica o cronograma para o desenvolvimento; Garantia da Qualidade de Software: Determina atividades iro ajudar a garantir a qualidade do produto; Definio da Estrutura de Decomposio do Trabalho: Determina as sub-tarefas necessrias para o desenvolvimento do produto; Elaborao do Design: Determina como o software dever prover as funcionalidades (caractersticas tcnicas/tecnolgicas); Elaborao do Design Arquitetural: Projeta a estrutura do sistema; Elaborao do Design de Interface: Especifica as interfaces entre as partes do sistema; Elaborao do Design Detalhado: Projeta os algoritmos e estrutura de dados para cada componente; Elaborao do Design de Banco de Dados: Especifica o(s) modelo(s) de banco de dados; Implementao: Construo do software; Teste: Execuo do software com dados para ajudar a garantir que o software funciona corretamente; Teste de Unidade: Teste do desenvolvedor original; Teste de Integrao: Teste durante a integrao do software; Teste do Sistema: Teste do software em um ambiente semelhante ao ambiente operacional; Teste Alpha: Teste pelo cliente no ambiente do desenvolvedor; Teste Beta: Teste pelo cliente no seu ambiente; Teste de Aceitao: Teste para satisfazer o cliente; Teste de Regresso: Teste de armazenamento da verso anterior para garantir que a nova verso possui todas as capacidades anteriores; Entrega: Prov o cliente com uma soluo de software eficiente; Implantao: Torna o software disponvel no ambiente operacional do cliente; Treinamento: Ensina o usurio como operar o software; Help desk: Responde a questes do usurio; Manuteno: Atualizao e evoluo do software para garantir usabilidade constante.
3.5 MODELOS DE PROCESSO DE SOFTWARE

Conforme destaca Pressman (2006): ... A aplicao inteligente de qualquer modelo de processo de software deve reconhecer que a adaptao (ao problema, ao projeto, equipe e cultura organizacional) essencial para o sucesso. Mas os modelos de processo diferem fundamentalmente: No fluxo geral de atividades e tarefas e interdependncias entre atividades e tarefas; No grau em que as tarefas de trabalho so definidas dentro de cada atividade de arcabouo; No grau em que os produtos do trabalho so identificados e solicitados; Na maneira como as atividades de garantia de qualidade so aplicadas; No modo como o monitoramento de projeto e as atividades de controle so aplicadas; No grau geral de detalhes e rigor em que o processo descrito; No grau em que clientes e outros interessados esto envolvidos no projeto; No nvel de autonomia da equipe de projeto de software; No grau em que a organizao da equipe e os papis so prescritos.
Modelos de processo que enfatizam a definio, identificao e aplicao detalhada de atividades e tarefas de processo tm sido aplicados na comunidade de engenharia de software durante os ltimos trinta anos. Quando esses Modelos Prescritivos de Processo so aplicados, o objetivo melhorar a qualidade do sistema para tornar os projetos mais gerenciveis, as datas de entrega e os custos mais previsveis e para guiar equipes de engenheiros de software medida que eles realizam o trabalho necessrio para construir um sistema. Infelizmente, tem havido pocas em que esses objetivos no tm sido alcanados. Se os modelos prescritivos forem aplicados dogmaticamente e sem adaptao, eles podem aumentar o nvel de burocracia associado construo de sistemas baseados em computador e, inadvertidamente, criar dificuldades para desenvolvedores e clientes. Modelos de processo que enfatizam a agilidade do projeto e seguem uma srie de princpios que levam a uma abordagem mais informal (mas, segundo seus proponentes, no menos efetiva) do processo de software foram propostos nos ltimos anos. Esses Modelos de Processo gil enfatizam a manobrabilidade e a adaptabilidade. Eles so adequados a muitos tipos de projeto e so particularmente teis quando aplicaes Web passam por engenharia. Que filosofia de processo de software melhor? Essa questo tem provocado um debate emocional entre engenheiros de software [...]. Por hora, importante notar que essas duas filosofias de processo tm objetivo comum criar softwares de alta qualidade que satisfaam s necessidades do cliente -, mas abordagens diferentes.
3.5.1 SELECIONANDO UM MODELO DE PROCESSO

[...] Cada ao de engenharia de software representada por um nmero diferente de conjuntos de tarefas cada um como uma coleo de tarefas de trabalho de engenharia de software, produtos de trabalho relacionados, pontos de garantia de qualidade e marcos de projeto. O conjunto de tarefas escolhido o que melhor acomoda as necessidades do projeto e as caractersticas da equipe. Isso implica que uma ao de engenharia de software (por exemplo, o projeto) pode ser adaptada s necessidades especficas do projeto de software e s caractersticas da equipe do projeto. No que se refere diretamente aos modelos de processo, Pressman ainda complementa: [...] Um conjunto de elementos de processo atividades de arcabouo, aes de engenharia de software, tarefas, produtos de trabalho, mecanismos de garantia de qualidade e de controle de modificaes
para cada projeto. Cada modelo de processo tambm prescreve um fluxo de trabalho isto , a maneira como os elementos do processo se inter-relacionam uns com os outros.
Origem: Wikipedia
Os modelos existentes possuem diferentes graus de sofisticao e complexidade. Para projetos que envolvem uma equipe de desenvolvimento pouco numerosa e experiente, o mais adequado ser provavelmente um processo simples. No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas de elementos e milhares de utilizadores, um processo simples no suficiente para oferecer a estrutura de gesto e disciplina necessrias engenharia de um bom produto de software. Desta forma, necessrio algo mais formal e disciplinado. importante fazer notar que isto no significa que se perca em inovao ou que se pe entraves criatividade. Significa apenas que utilizado um processo bem estruturado para permitir a criao de uma base estvel para a criatividade. Por mais simples ou complexo que possa parecer, um modelo de ciclo de vida de um projeto , de fato, uma verso simplificada da realidade. suposto ser uma abstrao e, tal como todas as boas abstraes, apenas a quantidade de detalhe necessria ao trabalho em mos deve ser includa. Qualquer organizao que deseje pr um modelo de ciclo de vida em prtica ir necessitar de adicionar detalhes especficos para dadas circunstncias e diferentes culturas. Por exemplo, a Microsoft quis manter uma cultura de pequena equipe e ao mesmo tempo tornar possvel o desenvolvimento de grandes e complexos produtos de software. Dependendo do tipo de sistema em desenvolvimento pode no ser completamente possvel ou at apropriado seguir os modelos rigorosamente.
3.5.2 RESUMINDO
Sobre Modelos de Processo: o o o o Especificam as atividades que, de acordo com o modelo, devem ser executadas, assim como a ordem em que devem ser executadas; Produtos de software podem ser construdos utilizando-se diferentes modelos de processo; Alguns modelos so mais adequados que outros para determinados tipos de aplicao; A opo por um determinado modelo deve ser feita levando-se em considerao o produto a ser desenvolvido, as pessoas envolvidas, os recursos disponveis, e vrios outros parmetros;
Objetivos: o o o Auxiliar no processo de produo Produtos de alta qualidade, produzidos mais rapidamente e a um custo cada vez menor; Atributos: complexidade, visibilidade, aceitabilidade, confiabilidade, manutenibilidade, segurana, etc; Possibilitam: Ao gerente: controlar o processo de desenvolvimento de software; Ao desenvolvedor: obter a base para produzir, de maneira eficiente, software que satisfaa os requisitos pr-estabelecidos.
3.5.3 PANORAMA SOBRE MODELOS PRESCRITIVOS DE PROCESSO

O que ? Modelos prescritivos de processo definem um conjunto distinto de atividades, aes, tarefas, marcos e produtos de trabalho que so necessrios para fazer engenharia de software com alta qualidade. Esses modelos de processo no so perfeitos, mas efetivamente fornecem um roteiro til para o trabalho da engenharia de software; Quem faz? Engenheiros de software e seus gerentes adaptam um modelo de processo prescritivo a suas necessidades e depois o seguem. Alm disso, o pessoal que solicitou o software tem um papel a desenvolver medida que o modelo de processo seguido; Por que importante? Porque fornece estabilidade, controle e organizao a uma atividade que pode, se deixada sem controle, tornar-se bastante catica. Alguns tm-se referido a modelos prescritivos de processo como modelos de processo rigorosos, porque eles frequentemente incluem as capacitaes sugeridas pelo CMMI. No entanto, cada modelo de processo deve ser adaptado para que seja usado efetivamente em um projeto de software especfico; Quais so os passos? O processo dirige uma equipe de software por meio de um arcabouo de atividades guarda-chuva que so organizadas em um fluxo de processo que pode ser linear, incremental ou evolutivo. A terminologia e os detalhes de cada modelo de processo diferem, mas as atividades genricas de arcabouo permanecem razoavelmente consistentes; Qual o produto do trabalho? Do ponto de vista de um engenheiro de software, os produtos de trabalho so os programas, documentos e dados que so produzidos em consequncia das atividades e tarefas definidas pelo processo; Como tenho certeza de que fiz corretamente? Existem diversos mecanismos de avaliao de processo de software que permitem s organizaes determinar a maturidade do seu processo de software. Todavia, a qualidade, pontualidade e viabilidade no longo prazo do produto que voc constri so os melhores indicadores da eficcia do processo usado.
Ainda sobre Modelos de processos prescritivos o autor destaca o seguinte: Se os modelos prescritivos de processo buscam estrutura e ordem, sero apropriados ao mundo do software que busca modificaes? No entanto, se rejeitarmos modelos de processos convencionais (e a ordem que eles implicam) e os substituirmos por algo menos estruturado, tornamos impossvel obter coordenao e coerncia no mundo de software? No h respostas fceis para essas questes, mas existem alternativas disponveis para os engenheiros de software.
A seguir sero apresentados alguns dos modelos prescritivos de processo mais conhecidos.
3.5.4 CODE AND FIX (CONSTRI E CONSERTA)

O code-and-fix no um modelo prescritivo de processo, mas uma primeira ideia de um processo de software. O produto construdo sem qualquer especificao ou design. No existe um roteiro definido de atividades, simplesmente vai-se se implementando medida que o contato com o cliente vai identificando novas necessidades. O produto refeito quantas vezes forem necessrias para satisfazer o cliente. Este modelo pode funcionar razoavelmente para micro projetos. No entanto para projetos maiores ele inadequado. A Figura a seguir caracteriza o modelo.
3.5.5 CLSSICO / EM CASCATA

Este modelo classificado como sendo um Modelo Prescritivo de Processo. Apesar de todos os seus problemas, o modelo em cascata utilizado h muitos anos, alm de ser o mais antigo dos modelos. Atualmente, devido complexidade cada vez maior dos sistemas, ele pouco utilizado. Suas principais caractersticas: Mtodo sistemtico e sequencial; O resultado de uma fase se constitui na entrada de outra - Cada atividade uma fase distinta. S aps o seu total trmino que a prxima atividade comea; O nvel de abstrao vai diminuindo medida que se avana no processo enquanto o formalismo aumenta; Cada fase estruturada como um conjunto de atividades que podem ser executadas por pessoas diferentes; Os requisitos do problema devem estar bem compreendidos.
Diferentes autores podem considerar diferentes atividades a serem trabalhadas (mesmo que elas tenham caractersticas em comum). No entanto o que est acima descrito se aplica a qualquer conjunto de atividades consideradas. Pressman (2006), por exemplo, ao invs das atividades que esto abaixo identificadas trabalha com as atividades que chama de arcabouo, e que j foram previamente citadas.
Atividades do Ciclo de Vida Clssico
Alguns problemas do Ciclo de Vida Clssico: Os projetos reais raramente seguem o fluxo sequencial que o modelo prope. Alguma iterao sempre ocorre e traz problemas na aplicao do paradigma; Muitas vezes difcil para o cliente declarar todas as exigncias explicitamente. O ciclo clssico tem dificuldade de acomodar a incerteza natural que existe no comeo de muitos projetos; Uma verso de trabalho do(s) programa(s) s estar disponvel em um ponto muito tardio do cronograma do projeto. O cliente deve ter pacincia; No modelo em cascata os subprocessos so executados em estrita sequncia, o que permite demarc-los com pontos de controle bem definidos. Essa caracterstica facilita a gesto dos projetos. Por outro lado, se interpretado literalmente, um processo rgido e burocrtico, em que as atividades devem ser muito bem dominadas, pois no so permitidos erros (retornar aps uma etapa ter sido concluda); [...] A natureza linear do modelo em cascata leva a estados de bloqueio nos quais alguns membros da equipe de projeto precisam esperar que outros membros completem as tarefas dependentes.
Realimentao entre fases Na prtica, sempre necessrio permitir que, em fases posteriores, haja reviso e alterao de resultados das fases anteriores. Por exemplo, os modelos e documentos de projeto podem ser alterados durante a implementao, medida que os problemas vo sendo descobertos. Uma variante que permite superposio entre fases e a realizao de correes um modelo mais realista, com realimentao entre as fases. Esta realimentao dificulta gerenciar projetos baseados neste modelo de processo.
3.5.6 INCREMENTAL
Este modelo classificado como sendo um Modelo Prescritivo de Processo. O modelo incremental e iterativo foi proposto como uma resposta aos problemas encontrados no modelo em cascata. Um processo de desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos, com o software sendo desenvolvido em partes (incrementos). Em cada ciclo de desenvolvimento, podem ser identificadas todas as fases do projeto. Essa caracterstica contrasta com a abordagem clssica, na qual as fases do projeto so realizadas uma nica vez. Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos so desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No prximo ciclo, um outro subconjunto dos requisitos considerado para ser desenvolvido, o que produz um novo incremento do sistema que contm extenses e refinamentos sobre o incremento anterior. Assim, o desenvolvimento evolui em verses, atravs da construo incremental e iterativa de novas funcionalidades at que o sistema completo esteja construdo. Vale destacar que apenas uma parte dos requisitos considerada em cada ciclo de desenvolvimento. Na verdade, um modelo iterativo e incremental pode ser visto como uma generalizao da abordagem em cascata: o software desenvolvido em incrementos e cada incremento desenvolvido em cascata (figura abaixo). A abordagem incremental e iterativa somente possvel se existir um mecanismo para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de desenvolvimento. Essa alocao realizada em funo do grau de importncia atribudo a cada requisito.
3.5.7 RAD (RAPID APPLICATION DEVELOPMENT)

Este modelo classificado como sendo um Modelo Prescritivo de Processo, e incremental. O desenvolvimento rpido de aplicao um modelo de processo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento extremamente curto (por exemplo, de 60 a 90 dias). uma adaptao do modelo cascata, no qual o desenvolvimento rpido conseguido com o uso de uma abordagem de construo baseada em componentes, requerendo que os requisitos sejam bem compreendidos, os objetivos propostos e haja diferentes equipes de desenvolvimento envolvidas. (PRESSMAN, 2006). Pressman (2006) ainda destaca os possveis problemas de tal abordagem: Aumento da necessidade de recursos humanos (tamanho das equipes), a medida que o escopo do problema aumenta;; Necessidade de maior envolvimento e comprometimento, para cumprir os prazos curtos; O problema precisa ser adequadamente modularizado, para que haja atuao das diferentes equipes; Em projetos de alto desempenho, com interfaces de mdulos muito interligadas, h maior probabilidade de erros; Pode no ser a abordagem mais adequada quando os riscos tcnicos so altos, como por exemplo, na utilizao de uma nova tecnologia.
3.5.8 MODELOS EVOLUCIONRIOS

Sobre modelos de processo evolucionrios Pressman (2006) destaca o seguinte: O software, como todo sistema complexo, evolui com o passar do tempo. Os requisitos do negcio e do produto mudam frequentemente medida que o desenvolvimento prossegue, dificultando um caminho direto para um produto final; prazos reduzidos de mercado tornam impossvel completar um produto de software abrangente, mas uma verso reduzida pode ser elaborada para fazer frente competitividade ou s presses do negcio; um conjunto de requisitos bsicos de um produto ou sistema bem entendido, mas os detalhes das extenses do produto ou sistema ainda precisam ser definidos. Nesse caso, e em situaes semelhantes, os engenheiros de software precisam de um modelo de processo que tenha sido explicitamente projetado para acomodar um produto que evolui com o tempo. O mesmo autor ainda prossegue, destacando a necessidade dos modelos evolucionrios: [...] software de computador moderno caracterizado por modificaes contnuas, prazos muito curtos por uma enftica necessidade de satisfao do cliente/usurio. Em muitos casos, o perodo at colocao no mercado o requisito gerencial mais importante. Se um nicho de mercado perdido, projeto de software em si pode ser insignificante. Pressman (2006) destaca tambm alguns problemas que esse tipo de modelo acarreta: Dificulta o planejamento de projeto, pois h um nmero incerto de ciclos para construir o produto; A velocidade da evoluo pode acarretar problemas no prprio produto; So processos focados na flexibilidade e extensibilidade, em detrimento de outros critrios de qualidade. o e a o
3.5.8.1
Prototipagem
A prototipagem pode ser considerada como um modelo de processo de desenvolvimento de software, mas que pode funcionar concomitantemente com qualquer outro tipo de modelo. No desenvolvimento de um software, a prototipagem um esboo de uma parte do sistema. Prottipos so construdos para telas de entrada, de sada, para subsistemas ou mesmo para todo um sistema. A construo de prottipos costuma utilizar as denominadas linguagens de programao visuais. Exemplos so o Delphi , o PowerBuilder e o Visual Basic que costumam ter ambientes com facilidades para a construo da interface grfica (telas, formulrios etc.). Alm disso, alguns sistemas gerenciadores de bancos de dados tambm fornecem ferramentas para a construo de telas de entrada e sada de dados.
Coleta e Refinamento dos Requisitos
Incio Fim Engenharia do Produto
Projeto Rpido
Refinamento do Prottipo
Construo do Prottipo
Avaliao do Prottipo pelo Cliente
Esse modelo constri uma verso descartvel (ou prottipo). Esse prottipo visa a testar conceitos e requisitos e ser usado para demonstrar o comportamento aos clientes. Aps a concordncia dos clientes, o software desenvolvido seguindo as mesmas fases do modelo clssico, ou de algum outro modelo que seja adotado. O esforo despendido no prottipo geralmente compensado pelo no desenvolvimento de caractersticas desnecessrias. Pode assumir 3 formas: (1) Um prottipo em papel ou automatizado; (2) Um prottipo de trabalho que implementa algum subconjunto da funo exigida do software desejado; (3) Um programa existente que executa parte ou toda a funo desejada. O funcionamento bsico o seguinte: A prototipao inicia-se com a coleta dos requisitos. O desenvolvedor e o cliente renem-se e definem os objetivos globais para o software. Ocorre ento a elaborao de um design rpido. O design rpido leva a construo de um prottipo que avaliado pelo cliente/usurio e usado para refinar os requisitos para o software a ser desenvolvido. Idealmente, o prottipo serve como um mecanismo para identificar os requisitos de software, quando h muitas dvidas entre estes. A prototipao fundamental medida que cresce a importncia da interface com o usurio. O prottipo pode servir como o primeiro sistema sistema esse que recomenda-se seja jogado fora. O problema que alguns usurios tendem a encarar o prottipo como algo j confivel, ou seja, como se j fosse parte do software real.
Na maioria dos projetos, o primeiro sistema construdo, se for via prottipo, dificilmente usvel. Ele pode ser muito lento, muito grande, desajeitado em uso, ou todos os trs. No resta outra alternativa seno comear tudo de novo, mas com mais habilidade tcnica. O desenvolvedor pode no utilizar as tcnicas de programao adequadas, pensando apenas na rapidez. Um prottipo normalmente preocupa-se apenas com a interface, no tratando dos algoritmos e regras de negcio. Esse , portanto mais um motivo para que ele seja descartado, ao invs de servir de base para o software final. Ainda que possam ocorrer problemas, a prototipao um paradigma eficiente da engenharia de software. A chave definir-se as regras do jogo logo no comeo, ou seja, o cliente e o desenvolvedor devem ambos concordar que o prottipo seja construdo para servir como um mecanismo afim de definir os requisitos. Ele ser depois descartado (pelo menos em parte) e o software real ser projetado.
3.5.8.2
Espiral ou Evolutivo
Coleta inicial dos Requisitos e Planejamento do Projeto
Este modelo classificado como sendo um Modelo Prescritivo de Processo, e evolucionrio.

Anlise dos riscos baseada nos requisitos iniciais Anlise dos riscos baseada na reao do cliente Planejamento baseado nos comentrios do cliente
Planejamento
Anlise dos Riscos
Deciso de Prosseguir ou no Na direo de um sistema concluido
Avaliao do cliente Avaliao do Cliente Engenharia
Prottipo de Software inicial
Prottipo de nvel seguinte Sistema construido pela engenharia
Este um modelo que atende os seguintes casos: O problema a ser resolvido no est totalmente entendido; A realidade pode mudar enquanto o sistema est sendo desenvolvido; A prpria soluo adotada pode ter algum efeito colateral desconhecido; A preocupao est centrada mais na qualidade e funcionalidade do que se produz.
O modelo espiral para a engenharia de software foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico (no que se refere a sistematizao e controle) como da prototipao (no que se refere a iteratividade), acrescentando, ao mesmo tempo, um novo elemento a anlise dos riscos que falta a esses paradigmas. O modelo, representado pela espiral, define quatro importantes atividades representadas pelos quatro quadrantes da figura, sendo elas:
1. Planejamento: determinao dos objetivos, alternativas e restries. 2. Anlise dos riscos: anlise de alternativas e identificao/resoluo dos riscos. 3. Engenharia: desenvolvimento do produto no nvel seguinte. 4. Avaliao pelo cliente: avaliao dos resultados da engenharia. No modelo em Espiral o produto desenvolvido em uma srie de iteraes. Cada nova iterao corresponde a uma volta na espiral. Isso permite construir produtos em prazos curtos, com novas caractersticas e recursos que so agregados medida que a experincia descobre sua necessidade. As atividades de avaliao so usadas para identificar problemas. Seus registros fornecem dados para definir os requisitos das prximas liberaes. As verses progressivamente mais completas do software so construdas ao longo de cada iterao da espiral. Durante o incio do giro, os objetivos, alternativas e restries so definidos, e os riscos so identificados e analisados. A concluso da anlise dos riscos resulta numa deciso de prosseguir ou no. Se os riscos forem muito grandes, o projeto pode ser encerrado. H o desenvolvimento de parte do programa, que disponibilizado para testes. Ento o cliente avalia o trabalho de engenharia e apresenta sugestes para modificaes. Cada passagem pela regio de planejamento resulta em ajustes no plano de projeto. O custo e o cronograma so ajustados com base no feedback derivado do cliente aps a entrega. Alm disso, o gerente do projeto ajusta o nmero planejado de iteraes necessrias para completar o software (Pressman, 2006). Deve-se notar que o nmero de atividades de desenvolvimento que ocorre no quadrante inferior direito eleva-se medida que as atividades se afastam do centro da espiral. O paradigma do modelo espiral usa a prototipao como um mecanismo de reduo dos riscos, possibilitando que o desenvolvedor aplique a abordagem de prototipao em qualquer etapa da evoluo do produto. O modelo espiral exige uma considerao direta dos riscos tcnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemticos. Ele exige considervel experincia na avaliao dos riscos e fia-se nessa experincia para o sucesso. Se um grande risco no for descoberto, indubitavelmente ocorrero problemas. O principal problema do ciclo de vida em espiral que ele requer gesto muito sofisticada para ser previsvel e confivel. E pode ser difcil convencer os clientes sobre a realizao de controle em tal forma de trabalho, visto os constantes ajustes que so realizados. Vale destacar que o modelo em espiral pode ser continuamente utilizado, aps a concluso inicial do software, para a realizao das manutenes que o mesmo dever sofrer ao longo do tempo. Uma outra figura interessante apresentada por Sommerville (2007), e est a seguir destacada.
3.5.8.3
Concorrente
Este modelo classificado como sendo um Modelo Prescritivo de Processo, e evolucionrio. O modelo concorrente representado atravs de uma srie de atividades e seus estados correspondentes. Sobre ele pode ser dito o seguinte: As atividades podem ocorrer em paralelo, mas esto em diferentes estados; O modelo define uma srie de eventos que vo disparar transies de estado para estado, para cada uma das atividades; Em vez de usar uma sequncia como o modelo cascata, ele define uma rede de atividades; Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma viso exata de como est o estado do projeto.
Um exemplo de uma rede de atividades pode ser como o da figura a seguir.
none Modeling act ivit y
Under development
represent s t he st at e of a sof t ware engineering activit y or task
Await ing changes
Under review Under revision Baselined
Done
3.5.9 DESENVOLVIMENTO BASEADO EM COMPONENTES

um modelo desenvolvido para apoiar a reusabilidade, necessria ao atual desenvolvimento de software, por suas principais consequncias: reduo de prazo e custo. Tal modelo se utiliza de componentes de software comercial de prateleira, isto , componentes que apresentam funcionalidade e interface bem definidas e que podem ser utilizados integrados no software em desenvolvimento. Incorpora muitas das caractersticas do modelo espiral. um modelo evolucionrio por natureza, demanda uma abordagem iterativa. Normalmente, apresenta os seguintes passos: Pesquisa e avaliao de componentes disponveis no mercado; Anlise das necessidades de integrao/implementao; Projeto da arquitetura de software, considerando os componentes; Integrao e Implementao que for necessria; Validao rigorosa.
3.5.10
O MODELO DE MTODOS FORMAIS
Os modelos de mtodos formais abrangem um conjunto de atividades que levam especificao matemtica formal do software de computador. So modelos que se apiam na aplicao de uma rigorosa notao matemtica. Tem ganhado adeptos quando h necessidade do desenvolvimento de softwares crticos em termos de segurana, devido sua promessa de um produto livre de erros. Vantagens: Ambiguidades, inconcluses e inconsistncias podem ser descobertas e corrigidas mais facilmente, por meio de anlise matemtica; Problemas: o o o O desenvolvimento de modelos formais atualmente muito lento e dispendioso; Como poucos desenvolvedores de software tm o preparo necessrio para aplicar mtodos formais, torna-se necessrio um treinamento extensivo; difcil usar os modelos como um mecanismo de comunicao, com clientes despreparados tecnicamente.
3.5.11
DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS
Certas preocupaes transversais cobrem toda a arquitetura de um sistema, no sendo exclusivas de uma funcionalidade, caracterstica ou informao. Por exemplo: segurana, tolerncia a falhas, transaes, gerao de logs. Assim, pode-se definir: Aspectos: mecanismos que transcendem subrotinas e herana para localizar a expresso de uma preocupao transversal, afetando toda a arquitetura de software. No existe ainda processo orientado a aspectos que seja considerado suficientemente maduro, mas provvel que adote caractersticas tanto do modelo de processo espiral quanto do concorrente. Alguns termos que comeam a se tornar conhecidos: POA Programao Orientada a Aspectos; DSOA Desenvolvimento de Software Orientado a Aspectos.
3.5.12
Origem:
PROCESSO UNIFICADO (PU)
http://paginas.terra.com.br/negocios/processos2002/processo_unificado_e_rup.htm Engenharia de Software, Roger Pressman, 2006 Engenharia de Software, Notas de Aula, prof. Ricardo de Almeida Falbo, UFES
De acordo com Pressman (2006), o PU uma tentativa de apoiar-se nos melhores recursos e caractersticas dos modelos convencionais de processo de software, mas caracteriz-los de um modo que implemente os melhores princpios de desenvolvimento gil de softwares. O Processo Unificado um processo de engenharia de software desenvolvido por trs dos principais gurus da indstria de software: Ivar Jacobson, James Rumbaugh e Grady Booch, sendo o resultado de mais de 30 anos de experincia acumulada. o primeiro processo de desenvolvimento a explorar integralmente as capacidades do padro UML e baseia-se nas prticas comuns aos projetos de software com mais alto ROI do mercado. Processo de Software Unificado (Rational Unified Process) = Processo + Mtodos + Linguagem (UML) Histrico:
O desenvolvimento de sistemas seguindo o RUP um processo: Dirigido por casos de uso (use cases); Centrado na arquitetura; Iterativo e incremental.
O RUP trata um conjunto de atividades: Bem definidas; Com responsveis; Com artefatos de entrada e sada; Com dependncias e ordem de execuo; Com modelo de ciclo de vida; Com uma descrio sistemtica de como execut-las; Usando linguagem UML.
Conceitos-chave do RUP:
fonte:http://www.dei.unicap.br/~sergio/es/aulas/09-IntroducaoRUP.pdf
O Processo Unificado proposto pela Rational (Rational Unified Process RUP) foi criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemtica para se obter reais vantagens no uso da Linguagem de Modelagem Unificada (Unified Modeling Language UML). De fato, ele no exatamente um processo: uma infraestrutura genrica de processo que pode ser especializada para uma ampla classe de sistemas de software, para diferentes reas de aplicao, tipos de organizao, nveis de competncia e tamanhos de projetos. O RUP est fundamentado em trs princpios bsicos: orientao a casos de uso, arquitetura e iterao. Ele dito dirigido a casos de uso, pois so os casos de uso que orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, so criados uma srie de modelos de anlise, design e implementao, que realizam estes casos de uso. centrado em arquitetura, pois defende a definio de um esqueleto para a aplicao (a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em pores menores ou mini-projetos. Esses trs conceitos so igualmente importantes. A arquitetura prov a estrutura para guiar o desenvolvimento do sistema em iteraes, enquanto os casos de uso definem as metas e conduzem o trabalho de cada iterao. O ciclo de vida adotado no RUP tipicamente evolutivo. Contudo, uma forma de organizao em fases adotada para comportar os ciclos de desenvolvimento, permitindo uma gerncia mais efetiva de projetos complexos. Ao contrrio do tradicionalmente definido como fases na maioria dos modelos de ciclo de vida planejamento, levantamento de requisitos, anlise, projeto, implementao e testes, so definidas fases ortogonais a estas, a saber: Concepo: nesta fase, estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a preciso necessria para se proceder estimativas de prazos e custos. As estimativas devem
ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a nfase nesta etapa recai sobre o planejamento e, por conseguinte, necessrio levantar requisitos do sistema e preliminarmente analis-los. Ao trmino dessa fase, so examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento; Elaborao: o propsito desta fase analisar mais refinadamente o domnio do problema, estabelecer uma arquitetura de fundao slida, desenvolver um plano de projeto para o sistema a ser construdo e eliminar os elementos de projeto que oferecem maior risco. Embora o processo deva sempre acomodar alteraes, as atividades da fase de elaborao asseguram que os requisitos, a arquitetura e os planos esto suficientemente estveis e que os riscos esto suficientemente mitigados, de modo a se poder prever com preciso os custos e prazos para a concluso do desenvolvimento. Construo: durante esta fase, um produto completo desenvolvido de maneira iterativa e incremental, para que esteja pronto para a transio comunidade usuria. Transio: nesta fase, o software disponibilizado comunidade usuria. Aps o produto ter sido colocado em uso, naturalmente surgem novas consideraes que vo demandar a construo de novas verses para permitir ajustes do sistema, corrigir problemas ou concluir algumas caractersticas que foram postergadas. importante realar que dentro de cada fase, um conjunto de iteraes, envolvendo planejamento, levantamento de requisitos, anlise, projeto e implementao e testes, realizado. Contudo, de uma iterao para outra e de uma fase para a prxima, a nfase sobre as vrias atividades muda, como mostra a figura 1 abaixo, em que a cor preta indica grande nfase, enquanto a cor branca indica muito pouca nfase.
Na fase de concepo, o foco principal recai sobre o entendimento dos requisitos e a determinao do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaborao, o enfoque est na captura e modelagem dos requisitos (levantamento de requisitos e anlise), ainda que algum trabalho de projeto e implementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de construo, o enfoque concentra-se no projeto e na implementao, visando evoluir e rechear o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a fase de transio concentra-se nos testes, visando garantir que o sistema possui o nvel adequado de qualidade. Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos esquecidos adicionados.
Alm dos conjuntos de iteraes em cada fase, as fases em si podem ocorrer de forma iterativa. Como mostra a figura 2, elas no necessariamente tm a mesma durao. O esforo realizado em cada uma varia fortemente em funo das circunstncias especficas do projeto.
Autor:
RICARDO
DE
ALMEIDA
FALBO
(fonte:
http://www.inf.ufes.br/~falbo/download/pub/Simpros2000.pdf)
Pressman (2006) destaca que as fases propostas no PU podem ser encaradas da mesma forma que as atividades de arcabouo por ele propostas, conforme destacado na figura abaixo:
Processo de Engenharia de Software na viso do RUP
Um processo um conjunto de passos ordenados com a inteno de atingir uma meta. Em engenharia de software, a meta criar um software ou aperfeioar um existente; em engenharia de processos, a meta desenvolver ou aperfeioar um processo. No RUP, eles so organizados em um conjunto de disciplinas para posteriormente definirem os fluxos de trabalho e outros elementos do processo. Em termos de modelagem de negcios, o processo de desenvolvimento de software um processo de negcios, e o Rational Unified Process (RUP) um processo de negcios genrico para engenharia de software orientada a objetos. Ele descreve uma famlia de processos de engenharia de software relacionados, que compartilham uma estrutura comum, uma arquitetura de processos comum. Ele proporciona uma abordagem disciplinada para a atribuio de tarefas e de responsabilidades dentro de uma organizao de desenvolvimento. Sua meta garantir a produo de software de alta qualidade que atenda s necessidades dos usurios, dentro de uma programao e um oramento previsveis. O RUP captura muitas das melhores prticas do desenvolvimento de software moderno, de forma que possam ser adaptadas para uma grande variedade de projetos e de organizaes. Quando um sistema de software desenvolvido comeando do zero, o desenvolvimento o processo de criao de um sistema a partir dos requisitos. Porm, depois que os sistemas tiverem tomado forma (ou seja, tiverem passado pelo ciclo de desenvolvimento inicial), os desenvolvimentos subsequentes sero o processo de adaptao do sistema aos requisitos novos ou modificados. Isso se aplica durante todo o ciclo de vida do sistema. Pressman (2006) destaca que nem toda tarefa identificada para um fluxo de trabalho do PU conduzida para qualquer projeto de software. A equipe adapta o processo (aes, tarefas, subtarefas e produtos de trabalho) para satisfazer s suas necessidades.
3.6 DESENVOLVIMENTO GIL 3.6.1 PANORAMA SOBRE DESENVOLVIMENTO GIL

O que ? A engenharia de software gil combina uma filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfao do cliente e a entrega incremental de software logo de incio; equipes de projeto pequenas, altamente motivadas; mtodos informais; produtos de trabalho de engenharia de software mnimos e simplicidade global de desenvolvimento. As diretrizes de desenvolvimento enfatizam a entrega em contraposio anlise e ao projeto (apesar dessas atividades no serem desencorajadas) e a comunicao ativa e contnua entre desenvolvedores e clientes; Quem faz? Engenheiros de software e outros interessados no projeto (gerentes, clientes e usurios finais) trabalham juntos em uma equipe gil uma equipe que auto-organizada e controla seu prprio destino. Uma equipe gil enfatiza a comunicao e a colaborao entre todos que a compe; Por que importante? O ambiente moderno de negcios que cria sistemas baseados em computador e produtos de software apressado e sempre mutvel. A engenharia gil de software representa uma alternativa razovel para a engenharia de software convencional para certas categorias de software e certos tipos de projeto de software. Tem sido demonstrado que ela entrega rapidamente sistemas bem-sucedidos; Quais so os passos? O desenvolvimento gil poderia ser melhor denominado pequena engenharia de software. As atividades bsicas de arcabouo comunicao com o cliente, o planejamento, a modelagem, construo, entrega e avaliao permanecem. Mas elas so
reduzidas a um conjunto mnimo de tarefas que leva a equipe de projeto construo e entrega (alguns alegariam que isso feito custa da anlise do problema e projeto da soluo); Qual o produto do trabalho? Clientes e engenheiros de software que tm adotado a filosofia gil tm a mesma impresso o nico produto de trabalho realmente importante um incremento de software operacional que entregue ao cliente na data de entrega combinada; Como tenho certeza de que fiz corretamente? Se a equipe gil concordar que o processo funciona e produz incrementos de software em condies de serem entregues e que satisfaam ao cliente, voc fez corretamente.
Comentrios: Os modelos de processo geis foram desenvolvidos em um esforo para vencer as fraquezas percebidas e reais da engenharia de software convencional; Pode fornecer importantes benefcios, mas ele no aplicvel a todos os projetos, produtos, pessoas e situaes; No contrrio slida prtica de engenharia de software, prevalecendo como uma filosofia sobre o trabalho de software; Os engenheiros de software devem ser geis o suficiente para responder a um ambiente de negcios mutante. E a engenharia de software est evoluindo para se adaptar a essa nova necessidade de agilidade.
Pressman (2006) apresenta ainda o Manifesto do Desenvolvimento gil de Software, onde declarado: Estamos descobrindo melhores modos de desenvolvimento de software, fazendo-o e ajudando outros a faz-lo. Por meio desse trabalho passamos a valorizar: Indivduos e interaes em vez de processos e ferramentas. Softwares funcionando em vez de documentao abrangente. Colaborao do cliente em vez de negociao de contratos. Resposta a modificaes em vez de seguir um plano. Isto , ainda que haja valor nos itens direita, valorizamos mais os itens esquerda.
3.6.2 O QUE AGILIDADE

Pressman (2006) destacou que no se deve cometer o erro de considerar que agilidade d ao engenheiro de software a licena de improvisar solues. A agilidade est relacionada a: Capacidade de responder rapidamente a mudanas; Estruturas e atitudes de equipe que tornam a comunicao mais fcil; Entrega rpida de software operacional; Menos importncia para produtos de trabalho intermedirios; Adoo dos clientes como parte da equipe de desenvolvimento; Planejamento em um mundo incerto tem limites e um plano de projeto deve ser flexvel.
O mesmo autor ainda destaca 12 princpios (propostos pelo Manifesto gil) que devem ser seguidos para se alcanar agilidade, sendo eles:
A mais alta prioridade a satisfao do cliente, por meio da liberao mais rpida e contnua de software de valor; Receba bem as mudanas de requisitos, mesmo em estgios tardios do desenvolvimento. Processos geis devem admitir mudanas que trazem vantagens competitivas para o cliente; Libere software frequentemente (em intervalos de 2 semanas at 2 meses), dando preferncia para uma escala de tempo mais curta; Mantenha pessoas ligadas ao negcio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto; Construa projetos com indivduos motivados, d a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado; O mtodo mais eficiente e efetivo para repassar informaes entre uma equipe de desenvolvimento pela comunicao face-a-face; Software funcionando a principal medida do progresso de um projeto de software; Processos geis promovem desenvolvimento sustentado. Assim, patrocinadores, desenvolvedores e usurios devem ser capazes de manter conversao pacfica indefinidamente; A ateno contnua para a excelncia tcnica e um bom projeto (design) aprimoram a agilidade; Simplicidade a arte de maximizar a quantidade de trabalho no feito essencial, devendo ser assumida em todos os aspectos do projeto; As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas; Em intervalos regulares, as equipes devem refletir sobre como se tornaram mais efetivas, e ento refinarem e ajustarem seu comportamento de acordo.
3.6.3 O QUE UM PROCESSO GIL

Qualquer processo gil caracterizado de modo que atenda a trs suposies-chave: difcil prever antecipadamente quais requisitos de software vo persistir e quais sero modificados. igualmente difcil prever como as prioridades do cliente sero modificadas medida que o projeto prossegue; O projeto e a construo so intercalados, isto , as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados medida que so criados. difcil prever o quanto de projeto necessrio antes que a construo seja usada para comprovar o projeto; Anlise, projeto, construo e testes no so to previsveis (do ponto de vista do planejamento) como gostaramos.
Pergunta: Como criar um processo que possa gerenciar a imprevisibilidade? Resposta: Um processo gil deve ser adaptvel e ser adaptado incrementalmente, com base no feedback do cliente.
3.6.4 POLTICA DE DESENVOLVIMENTO GIL

Ningum contra a agilidade (defensores de cada categoria de modelos de processo), o que se tem so respostas diferentes para as seguintes perguntas: Qual o melhor modo de alcanar a agilidade? Como construir softwares que satisfaam s necessidades do cliente atual e exiba caractersticas de qualidade que lhe permitam ser estendido e ampliado para satisfazer s necessidades do cliente no longo prazo?
No h respostas absolutas para as perguntas acima lanadas. H muito a ser ganho considerando o que houver de melhor em cada abordagem.
3.6.5 FATORES HUMANOS

O desenvolvimento gil enfoca os talentos e habilidades dos indivduos, moldando o processo a pessoas e equipes especficas. Caractersticas-chave que devem existir entre as pessoas de uma equipe gil e na equipe entre si: Competncia; Foco comum; Colaborao; Capacidade de tomada de deciso - autonomia; Habilidade de resolver problemas vagos; Respeito e confiana mtua; Auto-organizao. A equipe serve como sua prpria gerncia. o o o A equipe gil organiza-se para o trabalho a ser feito; A equipe organiza o processo para melhor acomodar seu ambiente local; A equipe organiza o cronograma de trabalho para conseguir melhor entrega do incremento de software.
Alguns modelos geis de processo que podem ser destacados so os seguintes:
3.6.6 EXTREME PROGRAMMING (XP)

Origem: Wikipdia, a enciclopdia livre.
Programao extrema (do ingls eXtreme Programming), ou simplesmente XP, uma metodologia gil para equipes pequenas e mdias e que iro desenvolver software com requisitos vagos e em constante mudana. Para isso, adota a estratgia de constante acompanhamento e realizao de vrios pequenos ajustes durante o desenvolvimento de software. Os quatro valores fundamentais da metodologia XP so: comunicao, simplicidade, feedback e coragem. A partir desses valores, possui como princpios bsicos: feedback rpido, presumir simplicidade, mudanas incrementais, abraar mudanas e trabalho de qualidade.
Dentre as variveis de controle em projetos (custo, tempo, qualidade e escopo), h um foco explcito em escopo. Para isso, recomenda-se a priorizao de funcionalidades que representem maior valor possvel para o negcio. Desta forma, caso seja necessrio a diminuio de escopo, as funcionalidades menos valiosas sero adiadas ou canceladas. A XP incentiva o controle da qualidade como varivel do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, no compensado por perdas (ou at impedimentos) a mdio e longo prazo. Prticas Para aplicar os valores e princpios durante o desenvolvimento de software, XP prope uma srie de prticas. H uma confiana muito grande na sinergia entre elas, os pontos fracos de cada uma so superados pelos pontos fortes de outras. Jogo de Planejamento (Planning Game): O desenvolvimento feito em iteraes semanais. No incio da semana, desenvolvedores e cliente renem-se para priorizar as funcionalidades. Essa reunio recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente essencial neste processo e assim ele fica sabendo o que est acontecendo e o que vai acontecer no projeto. Como o escopo reavaliado semanalmente, o projeto regido por um contrato de escopo negocivel, que difere significativamente das formas tradicionais de contratao de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produo. Pequenas Verses (Small Releases): A liberao de pequenas verses funcionais do projeto auxilia muito no processo de aceitao por parte do cliente, que j pode testar uma parte do sistema que est comprando. As verses chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. Metfora (Metaphor): Procura facilitar a comunicao com o cliente, entendendo a realidade dele. O conceito de rpido para um cliente de um sistema jurdico diferente para um programador experiente em controlar comunicao em sistemas em tempo real, como controle de trfego areo. preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto. Projeto Simples (Simple Design): Simplicidade um princpio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira verso apenas o usurio "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, voc vai fazer o cdigo exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticao e restries de acesso. Um erro comum ao adotar essa prtica a confuso por parte dos programadores de cdigo simples e cdigo fcil. Nem sempre o cdigo mais fcil de ser desenvolvido levar a soluo mais simples por parte de projeto. Esse entendimento fundamental para o bom andamento do XP. Cdigo fcil deve ser identificado e substitudo por cdigo simples. Time Coeso (Whole Team): A equipe de desenvolvimento formada pelo cliente e pela equipe de desenvolvimento. Testes de Aceitao (Customer Tests): So testes construdos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema. Ritmo Sustentvel (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudvel (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras so permitidas quando trouxerem produtividade para a execuo do projeto. Outra prtica que se verifica neste processo a prtica de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivao da equipe devem estar sempre em harmonia. Reunies em p (Stand-up Meeting): Reunies em p para no se perder o foco nos assuntos, produzindo reunies rpidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
Posse Coletiva (Collective Ownership): O cdigo-fonte no tem dono e ningum precisa solicitar permisso para poder modificar o mesmo. O objetivo com isto fazer a equipe conhecer todas as partes do sistema. Programao em Pares (Pair Programming): a programao em par/dupla num nico computador. Geralmente a dupla formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como apenas um computador, o novato que fica frente fazendo a codificao, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs). Com isto busca-se sempre a evoluo da equipe, melhorando a qualidade do cdigo fonte gerado. Padres de Codificao (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecer que todo o cdigo-fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitrios (unit tests) e depois crie o cdigo para que os testes funcionem. Esta abordagem complexa no incio, pois vai contra o processo de desenvolvimento de muitos anos. S que os testes unitrios so essenciais para que a qualidade do projeto seja mantida. Refatorao (Refactoring): um processo que permite a melhoria contnua da programao, com o mnimo de introduo de erros e mantendo a compatibilidade com o cdigo j existente. Refabricar melhora a clareza (leitura) do cdigo, divide-o em mdulos mais coesos e de maior reaproveitamento, evitando a duplicao de cdigo-fonte. Integrao Contnua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar verso atual do sistema. Isto s aumenta a possibilidade de conflitos e a possibilidade de erros no cdigo-fonte. Integrar de forma contnua permite saber o status real da programao.
O XP usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferencial. A metodologia do Extreme Programming possui 4 atividades de arcabouo:
Planejamento: o o o o o o o Criao de um conjunto de histrias que descrevem as caractersticas e funcionalidades requeridas. O cliente atribui uma prioridade para cada histria, com base no valor de negcio global da histria. Membros da equipe atribuem um custo s histrias medido em semanas de desenvolvimento. Se uma histria precisar de mais de 3 semanas, pede-se ao cliente para dividir a histria em histrias menores. Novas histrias podem ser escritas a qualquer momento. A equipe e o cliente renem-se para agrupar as histrias na verso seguinte e identificar o modo como elas sero desenvolvidas. Calcula-se a velocidade de projeto quantidade de histrias implementadas na primeira verso para ajudar a estimar datas futuras e verificar comprometimento com as histrias. Segue rigorosamente o princpio KIS (keep it simple mantenha simples), fornecendo apenas diretrizes de implementao. Encoraja o uso de cartes CRC (Classe-Responsabilidade-Colaborao) para identificar e organizar as classes orientadas a objetos que so relevantes para o incremento. Se um problema de projeto difcil encontrado, recomenda-se a criao imediata de um prottipo operacional, denominado Soluo de Ponta. Encoraja-se a refabricao processo de modificar um sistema de tal modo que ele no altere o comportamento externo do cdigo, mas aperfeioe a estrutura interna. O projeto visto como um artefato provisrio, continuamente modificado. Desenvolvimento de testes unitrios das histrias antes da codificao, exercitando a interface, as estruturas de dados e a funcionalidade do componente e possibilitando um feedback mais rpido quando o cdigo concludo. Programao em pares. Os focos so um pouco diferentes, poderia-se ter um programador pensando nos detalhes do cdigo e outro no atendimento das normas de programao. Integrao diria dos cdigos desenvolvidos pelos pares de programadores. Testes de regresso com os testes unitrios gerados anteriormente. Teste de integrao. Teste de validao. Teste de aceitao XP (testes do cliente).
Projeto: o o
o o o
Codificao: o
o Teste: o o o o
3.6.7 SCRUM
Origem: Wikipdia, a enciclopdia livre.
Scrum um mtodo gil para Gerenciamento de projetos. Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricao de automveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New New Product Development Game". Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes formao Scrum do Rugby (utilizada para reincio do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna documentaram, conceberam e implementaram o Scrum, como descrito abaixo, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo em desenvolvimento de software em todo o mundo. Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Takeuchi e Nonaka. A funo primria do Scrum ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porm, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de um casamento. Mesmo que o Scrum tenha sido idealizado para ser usado em gesto de projetos de desenvolvimento de software, ele tambm pode ser usado para gerenciar equipes de manuteno, ou como uma abordagem para gesto de programas: Scrum de Scrums. Caractersticas de Scrum Cada sprint uma iterao que segue o ciclo PDCA e entrega incremento de software pronto; Um backlog um conjunto de requisitos, priorizado pelo Product Owner (cliente); H entrega de conjunto fixo de itens do backlog em uma srie de iteraes curtas ou sprints; Breve reunio diria, ou scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm chamado de Standup Meeting ou Daily Meeting, j que os membros do time geralmente ficam em p); Breve sesso de planejamento, na qual os itens do backlog para uma sprint (iterao) so definidos; Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.
O Scrum facilitado por um Scrum Master, que tem como funo primria remover qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas), mas atua como um firewall entre a equipe e qualquer influncia desestabilizadora. Outra funo extremamente importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint. Scrum permite a criao de equipes auto-organizadas, encorajando a comunicao verbal entre todos os membros da equipe e entre todas as disciplinas que esto envolvidas no projeto. Um princpio chave do Scrum o reconhecimento de que desafios fundamentalmente empricos no podem ser resolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem emprica, aceitando que o problema no pode ser totalmente entendido ou definido, focando na maximizao da habilidade da equipe de responder de forma gil aos desafios emergentes. Um dos grandes defeitos do Scrum, porm, a abordagem de "receita de bolo" do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivo atingir qualidade atravs da aplicao de uma srie de processos prescritos.
Backlog de produto e backlog de sprint Um backlog uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto mantido pelo Proprietrio do Produto e uma lista de requisitos que tipicamente vm do cliente. O backlog de sprint uma interpretao do backlog do produto e contm tarefas concretas que sero realizadas durante o prximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint so, ento, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nvel e o segundo contendo informaes sobre como a equipe ir implementar os requisitos. Planejamento de sprint Antes de todo sprint, o Proprietrio do Produto, o Scrum Master e a Equipe decidem no que a equipe ir trabalhar durante o prximo sprint. O Proprietrio do Produto mantm uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe ento planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto so ento destrinchados em tarefas que se tornam o backlog do sprint. Scrum simplificado Muitas organizaes tm sido resistentes s metodologias introduzidas em baixos nveis da organizao. Porm, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisvel ("stealth"), usando os trs passos: Agende uma demonstrao do software com seu cliente em um ms a partir de agora; Como equipe, tome um ms para deixar o software pronto para uma demo, com funcionalidades prontas, no simplesmente telas; Na demonstrao, obtenha feedback e use-o para guiar o seu prximo ms de trabalho de desenvolvimento.
Algumas caractersticas de Scrum Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na sada); Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas; Planos frequentes de mitigao de riscos desenvolvidos pela equipe; Discusses dirias de status com a equipe; A discusso diria na qual cada membro da equipe responde s seguintes perguntas: o o o O que fiz desde ontem? O que estou planejando fazer at amanh? Existe algo me impedindo de atingir minha meta?
Transparncia no planejamento e desenvolvimento; Reunies frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso; Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer problema no visto; Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" no necessariamente significa "produzir mais".
Agendando discusses dirias Um momento bom para as discusses dirias depois do almoo. Durante a manh pode ser complicado. Estas discusses de status no demoram e uma forma eficiente de fazer estas reunies seria ficar em p e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoo, ter uma viva reunio em p nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manh, suas mentes esto focadas no trabalho e no em questes pessoais. Scrum Solo Scrum baseado em pequenas equipes. Ele permite a comunicao entre os membros da equipe. Entretanto, h uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um s programador pode ainda se beneficiar de alguns princpios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo uma verso adaptada para uso de programadores solo.
Algumas caractersticas seguidas pelo SCRUM: Pendncia lista priorizada de requisitos ou caractersticas do projeto que fornecem valor de negcio para o cliente. Itens podem ser adicionados a qualquer hora; Sprints unidades de trabalho que so necessrias para satisfazer a um requisito definido na pendncia que precisa ser cumprido em um intervalo de tempo definido (tipicamente 30 dias). Durante o sprint, os itens em pendncia a que as unidades de trabalho do sprint se destinam so congelados; Reunies Scrum so reunies curtas (normalmente 15 minutos) feitas diariamente pela equipe. Trs questes-chave so feitas e respondidas por todos: o o o O que voc fez desde a ltima reunio de equipe? Que obstculos voc est encontrando? O que voc planeja realizar at a prxima reunio?
Demos entrega o incremento de software ao cliente de modo que a funcionalidade implementada possa ser demonstrada e avaliada pela cliente.
3.6.8 FDD (FEATURE DRIVEN DEVELOPMENT)

Origem: Wikipdia, a enciclopdia livre
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 ocasio, o representante da FDD foi Jon Kern, que trabalhava na TogetherSoft, substituindo Peter Coad. Origens A FDD nasceu num projeto em Cingapura, entre 1997 e 1999, a partir do Mtodo Coad (uma metodologia completa para Anlise, Desenho e Programao Orientados a Objetos, desenvolvida por Peter Coad nas dcadas de 1980 e 1990) e das tcnicas de gerenciamento iterativo, incremental e enxuto de projetos utilizadas por Jeff De Luca, um gerente de projetos australiano. Seu lema "Resultados frequentes, tangveis e funcionais". A primeira descrio oficial dos processos foi publicada no livro "Java Modeling in Color with UML", por Peter Coad, Eric Lefebvre e Jeff De Luca, em 1999. O livro de referncia "A Practical Guide to Feature-Driven Development", por Stephen Palmer e John Mac Felsing, publicado em 2002 pela Prentice-Hall, compondo uma srie editada pelo prprio Peter Coad. FDD e a Famlia gil Com relao s outras metodologias de desenvolvimento de software, situa-se numa posio intermediria entre as abordagens mais prescritivas (Processo Unificado, Cascata tradicional Waterfall) e as abordagens geis (XP - Programao Extrema, Scrum, Crystal, etc.). Oferece um conjunto coeso de princpios e prticas tanto para a Gesto de Projetos quanto para a Engenharia de Software, mas convive bem com abordagens mais especialistas, como Scrum.
Apesar de algumas divergncias pontuais com a XP, vrias prticas propostas por esta ltima tambm so utilizadas por equipes usando FDD, como os testes unitrios, refatorao, programao em pares, integrao contnua, entre outras. Apenas a nfase na FDD que no to grande quanto na XP. A FDD tambm prope prticas como inspeo formal (de desenho e de cdigo) e posse individual/situacional de cdigo/classe, que podem contrastar com algumas das prticas fundamentais da XP. A experincia da equipe e dos gerentes que deve julgar quais prticas so mais apropriadas. Os Processos A FDD , classicamente, descrita por cinco processos: Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, anlise orientada a objetos, modelagem lgica de dados e outras tcnicas para entendimento do domnio de negcio em questo. O resultado um modelo de objetos (e/ou de dados) de alto nvel, que guiar a equipe durante os ciclos de construo. Construir uma Lista de Funcionalidades: decomposio funcional do modelo do domnio, em trs camadas tpicas: reas de negcio, atividades de negcio e passos automatizados da atividade (funcionalidades). O resultado uma hierarquia de funcionalidades que representa o produto a ser construdo (tambm chamado de product backlog, ou lista de espera do produto). Planejar por Funcionalidade: abrange a estimativa de complexidade e dependncia das funcionalidades, tambm levando em considerao a prioridade e valor para o negcio/cliente. O resultado um plano de desenvolvimento, com os pacotes de trabalho na sequncia apropriada para a construo. Detalhar por Funcionalidade: j dentro de uma iterao de construo, a equipe detalha os requisitos e outros artefatos para a codificao de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades inspecionado. O resultado o modelo de domnio mais detalhado e os esqueletos de cdigo prontos para serem preenchidos. Construir por Funcionalidade: cada esqueleto de cdigo preenchido, testado e inspecionado. O resultado um incremento do produto integrado ao repositrio principal de cdigo, com qualidade e potencial para ser usado pelo cliente/usurio.
Caracterstica uma funo valorizada pelo cliente que pode ser implementada em duas semanas ou menos; Define cinco atividades de arcabouo colaborativas (processos); O FDD coloca mais nfase em diretrizes e tcnicas de gesto de projeto do que muitos outros mtodos geis.
Benefcios: Como as caractersticas so pequenos blocos de funcionalidade passveis de entrega, os usurios podem descrev-las mais facilmente, entender como elas se relacionam umas com as outras e revis-las melhor quanto a ambiguidades, erros ou omisses; As caractersticas podem ser organizadas em um agrupamento hierrquico relacionado ao negcio; Como uma caracterstica um incremento de software passvel de entrega do FDD, a equipe desenvolve caractersticas operacionais a cada duas semanas; Como as caractersticas so pequenas, suas representaes de projeto e de cdigo so mais fceis de inspecionar; Planejamento de projeto, cronogramao e monitorao so guiados pela hierarquia de caractersticas em vez de por um conjunto de tarefas de engenharia de software arbitrariamente adotado.
3.7 AUTOMATIZAO DO PROCESSO DE SOFTWARE 3.7.1 AUTOMATIZAO DE PROCESSOS DE SOFTWARE

Origem: Dissertao de Mestrado - DEFINIO DE PROCESSOS EM UM AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE. Autor: Gleidson Bertolo. UFES. 2006.
Devido influncia do processo de software no desenvolvimento de produtos de software de qualidade, muito trabalho tem sido feito no sentido de apoiar organizaes em seus esforos pela busca da qualidade de processo. Conforme apontado por ARBAOUI et al. (2002), as pesquisas na rea de processos de software nos ltimos anos tm explorado duas principais vertentes: (i) abordagens para modelagem, anlise e melhoria do processo de software; (ii) tecnologia de apoio ao processo de software. A primeira vertente focaliza abordagens para estruturao, organizao, documentao e descrio de processos de software e inclui normas e modelos de qualidade de processo de software, tais como as apresentadas na seo anterior. A segunda vertente est voltada para o desenvolvimento de Ambientes de Desenvolvimento de Software (ADSs), que buscam combinar tcnicas, mtodos e ferramentas para apoiar o engenheiro de software na construo de produtos de software, abrangendo todas as atividades inerentes ao processo, tais como planejamento, gerncia, desenvolvimento e controle da qualidade. Os benefcios da utilizao de ADSs incluem (PRESSMAN, 2005): Facilitar a transferncia de informao entre ferramentas e, consequentemente, entre passos do processo de software; Reduzir os esforos para realizar atividades de gerncia de configurao, garantia de qualidade e produo de documentao; Aumentar o controle do projeto, atravs de melhor planejamento, monitoramento e comunicao; Prover coordenao entre os recursos humanos que esto trabalhando em um grande projeto de software.
A integrao de ferramentas ainda um dos maiores desafios dos ADSs, pois demanda representao consistente da informao, interfaces padronizadas, significados homogneos para a comunicao entre engenheiros de software e ferramentas, e uma efetiva abordagem que possibilite portar os ADSs para vrias plataformas (PRESSMAN, 2005). THOMAS e NEJMEH (1992), TRAVASSOS (1994), FALBO (1998) e PFLEEGER (2001), dentre outros, propem que a integrao de ferramentas em ADSs seja tratada atravs de uma infraestrutura que contemple vrias dimenses, dentre elas: Integrao de Dados: trata de servios de repositrio de dados, provendo armazenamento e gerncia de objetos, e integrao de dados, permitindo o compartilhamento de informaes entre as ferramentas; Integrao de Apresentao: diz respeito a servios de interface com o usurio. As interfaces de um ADS devem ser homogneas e consistentes, permitindo que os desenvolvedores alternem entre as ferramentas que utilizam, sem mudanas substanciais de estilo; Integrao de Controle: est relacionada aos servios de gerncia de funcionalidades e mensagens, permitindo uma ferramenta notificar ou iniciar uma ao em outra ferramenta, controlando os eventos ocorridos e compartilhando funcionalidades; Integrao de Processo: obtida pela ligao explcita entre ferramentas e o processo de software. Para integrar ferramentas, preciso ter um foco forte no gerenciamento do processo de software. O processo deve definir que ferramentas um engenheiro de software pode utilizar e quando dever ter acesso s mesmas, em funo da atividade que est realizando; Integrao de Plataforma: trata da independncia da plataforma sobre a qual funcionar a ferramenta;
Integrao de Conhecimento: diz respeito aos servios de gerncia de conhecimento, permitindo capturar conhecimento durante os projetos de software e oferecer apoio baseado em gerncia de conhecimento aos engenheiros de software durante a realizao de atividades do processo.
Devido s dificuldades inerentes ao controle de processos de software, a integrao de processo tem se mostrado to importante que deu origem a uma nova classe de ambientes, os Ambientes de Desenvolvimento de Software Centrados em Processo (ADSCPs). ADSCPs integram ferramentas para apoiar o desenvolvimento do software e para apoiar a modelagem e a execuo do processo de software utilizado para desenvolver este produto (HARRISON et al., 2000; FUGGETTA, 2000). Um ADSCP explora uma definio explcita do processo de software e pode ser visto como a automatizao parcial desse processo, incluindo mecanismos para (CHRISTIE, 1995): (i) guiar a sequncia de atividades definida; (ii) gerenciar os produtos que esto sendo desenvolvidos; (iii) executar ferramentas necessrias para a realizao das atividades; (iv) permitir comunicao entre as pessoas; (v) colher dados de mtricas automaticamente; (vi) reduzir erros humanos e (vii) prover controle do projeto medida que este vai sendo executado. Processos modelados em um ADSCP tipicamente descrevem as atividades a serem realizadas, os responsveis por cada uma delas e as ferramentas de software a serem utilizadas. So criados para vrios propsitos, dentre eles: documentao do processo de software, melhoria do processo de software, gerenciamento do fluxo de trabalho e automatizao (GRUHN, 2002). Desta forma, ao prover meios de descrever e implementar processos de engenharia de software, ADSCPs provem um mecanismo de integrao de processo e ferramentas e, parcialmente, de automatizao de tarefas (HARRISON et al., 2000). Alguns exemplos de ADSCPs citados em (HARRISON et al.,2000) incluem: Adele, Argo, PCTE e SPADE. Em (ARBAOUI et al., 2002) so citados TEMPO e APEL (construdos a partir do Adele), LEU, PEACE, PIE e OZ. HOLZ et al. (2001) e RICHTER e MAURER (2003) enfocam o ADSCP MILOS (Modeling Language and Operational Support for Software Processes), que prov meios para definir um modelo de processo genrico e configurar planos de projeto concretos baseados neste modelo. No contexto deste trabalho, dois ADSCPs merecem destaque: o ambiente ODE (FALBO et al., 2003), no qual este trabalho foi desenvolvido, e a Estao TABA (BERGER, 2003) que adota uma filosofia de definio de processos correlata apresentada neste trabalho. A seguir, esses dois ambientes so apresentados com maiores detalhes.
3.7.1.1
A Estao TABA
Origem: Dissertao de Mestrado - DEFINIO DE PROCESSOS EM UM AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE. Autor: Gleidson Bertolo. UFES. 2006.
A Estao TABA, desenvolvida desde 1990 (ROCHA et al., 1990), um meta-ambiente capaz de gerar ambientes de desenvolvimento de software adequados s particularidades de organizaes, processos de software e projetos especficos. Para tal, utiliza atualmente a abordagem de gerao de ambientes mostrada na Figura 2.3.
Figura 2.3 - Gerao de ambientes a partir da Estao TABA (BERGER, 2003)

Inicialmente, necessrio criar um Ambiente Configurado a partir das caractersticas da organizao e de sua maturidade em desenvolver software. O ambiente configurado contm o processo padro da organizao e os processos especializados para os paradigmas de desenvolvimento utilizados na organizao. Esse ambiente armazena e prov conhecimento capturado pela organizao, importante para o desenvolvimento e a manuteno de software. Um ambiente configurado contm uma ferramenta para apoiar a instanciao de processos, que tem a capacidade de gerar, a partir dos processos instanciados, ambientes de desenvolvimento de software para projetos especficos, os ditos Ambientes de Desenvolvimento de Software Orientados a Organizao (ADSOrg). Os ambientes instanciados so os ambientes que apiam o desenvolvimento dos produtos de software e contm outras ferramentas de apoio ao desenvolvimento (BERGER, 2003). A Estao TABA tambm um ADS Centrado em Processo, pois possibilita modelar explicitamente um processo de software e control-lo no ambiente instanciado. O ambiente possibilita, ainda, a gesto do conhecimento da organizao, definindo um repositrio de conhecimento que pode ser acessado pelos ADSOrg instanciados. O processo de instanciao descreve as atividades necessrias para se realizar a adaptao (instanciao) de um processo especializado para um projeto especfico, dentro do contexto de um Ambiente Configurado, a saber (BERGER, 2003): Pr-Condio: Identificao de Atividades Obrigatrias 1. Caracterizar Projeto 1.1 Definir Projeto 1.2 Identificar Caractersticas do Projeto 2. Planejar Processo 2.1 Incluir Atividades do Tipo de Software 2.2 Definir Modelo de Ciclo de Vida 2.3 Mapear Atividades do Modelo de Ciclo de Vida 2.3.1 Verificar a Existncia de Mapeamento Anterior 2.3.2 Realizar Mapeamento
2.4 Excluir Atividades No Pertinentes 2.5 Incluir Novas Atividades 2.6 Selecionar Tcnicas de Avaliao 2.7 Selecionar Ferramentas 3. Instanciao de ADSOrg para o projeto As atividades descritas so de responsabilidade do gerente do projeto. O resultado da instanciao um processo instanciado que constitui o Plano do Processo de Desenvolvimento para um projeto especfico. A cada novo projeto deve ser instanciado um novo ambiente (BERGER, 2003).
3.8 TEXTO COMPLEMENTAR

O Ambiente ODE
Origem: ODE, Laboratrio de Software, UFES (http://www.inf.ufes.br/~labes/ode/)
Alta qualidade e produtividade so fatores crticos no desenvolvimento de software. Neste contexto, torna-se essencial prover ferramentas para ajudar o engenheiro de software em suas tarefas. O suporte de ferramentas influencia diretamente o tempo de desenvolvimento do software, o seu custo [1] e a qualidade do produto desenvolvido . Assim, diversas ferramentas, conhecidas como ferramentas CASE (Computer-Aided Software Engineering), tm sido amplamente utilizadas no desenvolvimento de software. Entretanto, essas geralmente so ferramentas isoladas, que no so capazes de compartilhar servios, ou sequer informaes. Muito embora o uso de ferramentas individuais possa trazer benefcios em atividades separadas, o real poder dessas ferramentas de apoio somente pode ser alcanado atravs da [2] integrao . Dessa forma, Ambientes de Desenvolvimento de Software (ADSs) tm ganhado cada vez mais importncia. Tais ambientes buscam combinar tcnicas, mtodos e ferramentas para apoiar o engenheiro de software na construo de produtos de software, abrangendo todas as atividades [3] inerentes ao processo, tais como de gerncia, desenvolvimento e controle da qualidade . Um ADS tem o objetivo de ser um ambiente completo, capaz de suportar todo o processo de software, com diversas ferramentas integradas trabalhando em conjunto. ODE (Ontology-based software Development Environment) um ADS centrado em processo, fundamentado em ontologias. O ambiente ODE vem sendo desenvolvido no Laboratrio de Engenharia de Software da UFES (LabES) e implementado em plataforma livre, utilizando Java como linguagem de programao e banco de dados PostgreSQL. Algumas caractersticas de ODE que merecem destaque so: a uniformidade de conceitos provida pelas ontologias, que facilita a integrao, deixa o ambiente mais homogneo e torna mais efetiva a comunicao entre pessoas e entre ferramentas; a forte base em conhecimento, que permite que o ambiente oferea um suporte especializado ao usurio na realizao de suas tarefas e possibilita que as informaes geradas mantenham-se interligadas e consistentes ao longo de todo o processo; e o foco em ferramentas gerenciais, uma vez que a gerncia uma rea de grande importncia e ainda bastante carente em termos de ferramentas. A seguir, so brevemente apresentados os principais mdulos e ferramentas integradas atualmente ao ambiente ODE.
- Controle de Projetos (Manuteno e Caracterizao) ODE direcionado a projetos. Assim, a maior parte das funcionalidades do ambiente acessada no contexto de um projeto. O Ambiente permite que vrios projetos sejam criados e controlados. Dessa forma, os usurios tm acesso apenas aos projetos em que estejam alocados. Outro ponto relevante a Caracterizao de Projetos que possibilita a comparao entre projetos e, ento, a recuperao de projetos similares, muito importante nas tarefas que fazem uso de dados histricos. - Cadastro de Conhecimento (sobre Processos, Riscos e Qualidade) Permite que os dados organizacionais sejam registrados no ambiente. Com base nas ontologias existentes atualmente em ODE, possvel armazenar informaes a respeito de processos (modelos de ciclo de vida, atividades, recursos, artefatos, procedimentos etc.), riscos e mtricas de qualidade. Como as ferramentas integradas oferecem suporte fortemente baseado nesse conhecimento, possvel fornecer ao usurio apoio direcionado ao conhecimento organizacional.
<<Concept>> Procedure 0..* possible adoption 0..* sub-activity 0..* <<Concept>> Process 1 <<Concept>> Project 0..* team allocation 0..* 0..* use 0..* input 0..* <<Concept>> Software Tool 0..* <<Concept>> Human Resource <<Concept>> Resource <<Concept>> Team 0..*
implementation 1 0..1
0..* 0..* <<Concept>> Activity 0..*
product 0..* <<Concept>> Artifact
0..*
- Cadastro de Recursos Organizacionais Gerencia os recursos humanos, ferramentas de software e recursos de hardware da organizao, assim como os usurios do ambiente. Possibilita que os colaboradores sejam associados s funes que esto aptos a realizar, apoiando a alocao de recursos s atividades. Alm disso, registra as ferramentas de software utilizadas pela organizao atravs do ambiente, sejam elas parte integrante do ambiente, ou ferramentas externas desenvolvidas independentemente dele.
- Definio de Processos Por ser centrado em processo, ODE tem esta como uma de suas ferramentas mais centrais. nela que so definidos os processos que guiaro os projetos da organizao. A ferramenta utiliza um efetivo suporte do conhecimento para apoiar o gerente na definio de um modelo de ciclo de vida para o processo, de suas atividades, dos artefatos a serem produzidos e consumidos, dos recursos humanos, de software e de hardware necessrios execuo, e dos mtodos, tcnicas, roteiros e normas utilizados. Devido definio do processo, o ambiente capaz de se configurar de forma a melhor atender ao processo definido, exibindo as ferramentas que devem apoiar cada usurio nas atividades em que so necessrias. - Acompanhamento de Projetos Assim que um projeto iniciado, possvel acompanh-lo por esta ferramenta. O processo do projeto apresentado na forma de um grafo que exibe as atividades, destacando sua hierarquia, ordem de execuo e estados atuais. Para cada uma das atividades, so mostradas informaes relevantes como seus artefatos, procedimentos, recursos alocados e datas. Dessa forma, o gerente pode monitorar e controlar o andamento dos projetos.
- Alocao de Recursos Humanos Esta ferramenta apia a definio de equipes para projetos e a alocao de seus membros s atividades definidas. Com base na necessidade de recursos humanos de cada atividade (estipulada na definio de processos), os colaboradores da organizao podem ser alocados s atividades, sendo definidos seus papis, datas de alocao e dedicao. A partir da alocao, o ambiente se configura para permitir aos colaboradores acesso apenas s funcionalidades necessrias realizao das atividades em que esto alocados.
- Alocao de Ferramentas de Software De forma semelhante alocao de recursos humanos, esta ferramenta permite alocar as ferramentas da organizao s atividades que delas necessitam. A alocao vlida tanto para ferramentas internas quanto externas e tambm necessria configurao do ambiente, disponibilizando as ferramentas nos momentos em que devem ser utilizadas.
- GeRis - Gerncia de Riscos Gerenciar riscos um fator de grande importncia em qualquer projeto. GeRis apia a gerncia de riscos dos projetos de software e a elaborao de um plano de riscos. Com base no conhecimento organizacional sobre riscos, o gerente pode identificar os riscos relevantes a cada projeto; avali-los segundo suas probabilidades, impactos, e consequncias; selecionar aes adequadas de mitigao e contingncia e, por fim, gerar um plano de riscos para o projeto.
- Agenda e Registro de Esforo Atravs da ferramenta de agenda, os usurios do ambiente podem visualizar a quais atividades de que projetos esto alocados, as datas previstas e efetivas e o esforo registrado at o momento. Ao gerente de projetos, fornecida uma viso mais ampla do andamento das atividades. A ferramenta permite ainda que os usurios registrem os esforos despendidos diariamente nas atividades em que esto alocados.
- EstimaODE - Estimativas de Tamanho e Esforo Esta ferramenta possui uma estrutura comum que contempla trs abordagens de estimativas: - Anlise de Pontos de Funo: apia a realizao de estimativas de tamanho, utilizando a tcnica de
pontos de funo. Possibilita que o usurio inicie as estimativas, informe os dados das funes do sistema, registre os nveis de influncia relacionados e gere um relatrio com os pontos de funo determinados. Permite ainda que sejam feitas recontagens dos pontos de funo no decorrer do projeto, aproveitando a contagem anterior e mantendo um histrico para efeito comparativo. - Anlise de Pontos de Casos de Uso: utiliza a tcnica de pontos de casos de uso para tambm dar suporte realizao de estimativas de tamanho. Uma vez iniciada a estimativa, possvel determinar os pesos de atores e casos de uso, os fatores tcnicos e calcular os pontos de casos de uso. Tambm permite a gerao de relatrios e a recontagem de pontos. - Estimativa por Decomposio do Processo: apia a realizao de estimativas de esforo utilizando decomposio do processo e dados histricos de projetos similares. Permite estimar o esforo de projetos e suas atividades baseando-se em dados de esforos reais obtidos de projetos j realizados no ambiente. - Gerncia de Conhecimento Gerenciar o conhecimento produzido durante o desenvolvimento de software um fator de grande importncia e que traz vantagens realizao de projetos. ODE possui uma infra-estrutura de gerncia de conhecimento que composta por uma memria organizacional e por servios que permitem a criao, recuperao, disseminao, uso e manuteno de conhecimento. Alguns itens de conhecimento com os quais o ambiente lida so lies aprendidas e artefatos em geral. Com a utilizao da gerncia de conhecimento, os usurios podem registrar o conhecimento que adquirem no decorrer dos projetos no prprio ambiente, assim como buscar conhecimento registrado por outras pessoas da organizao.
Como pde ser observado, o ambiente ODE possui um abrangente corpo de ferramentas teis a vrias tarefas do desenvolvimento de software. Contudo, a pesquisa e o desenvolvimento continuam. Dessa forma, algumas ferramentas que j se encontram em fase de construo e em breve sero incorporadas ao ambiente so:
- Definio de Processos em Nveis A evoluo da ferramenta de definio de processos permitir que os processos sejam definidos em vrios nveis. Assim a organizao poder definir o seu Processo Padro, criar processos especializados a partir deste e instanciar os processos de projetos especficos. Essa hierarquizao possibilita que os processos no sejam mais definidos "a partir do zero", economizando tempo e esforos e garante uma padronizao entre os processos, alm de outras caractersticas de qualidade.
Normas e Modelos de Qualidade, Cultura Organizacional
Definio
Processo Padro
Especializao Tecnologia de Desenvolvimento, Domnio do Problema e Paradigma

Processo Especializado 1 Processo Especializado n
Instanciao
Processo de Processo de Alm disso, o ambiente dar suporte Projeto 1 Projeto m Particularidades criao de vrios processos por projeto, permitindo assim, o controle de outros processos alm do de desenvolvimento, tais como processos de gerncia, de avaliao da qualidade, de fornecimento, de manuteno etc.
- Manipulao de Conhecimento Organizacional O conhecimento sobre a organizao de grande importncia em projetos de software. Se este conhecimento for incorporado ao ambiente, a realizao de diversas tarefas pode ser melhorada. De posse de conhecimento sobre as unidades organizacionais, cargos, pessoal, competncias e atividades da organizao, o ambiente poder apoiar, com muito mais eficcia, tarefas como a definio de processos, alocao de recursos, direcionamento de perguntas, envio de informaes teis ao andamento do projeto, entre outras. - XMLDoc - Documentao Automatizada Por ser um ambiente integrado, ODE armazena em um repositrio nico todas as informaes manipuladas em suas ferramentas. Dessa forma, a documentao amplamente facilitada. Documentos como planos de projeto, definio de processos, planos de riscos, realizao de estimativas, alocao de recursos, modelos e diagramas, registros de esforos e outros mais podem ser facilmente recuperados a partir de XMLDoc. A ferramenta encontra-se em reestruturao e permitir a extrao de dados do repositrio para documentos XML, que ento, sero transformados para diversos formatos como HTML, PDF e RTF. - OODE Modelagem UML OODE uma ferramenta grfica para modelagem UML que permite a construo de diversos diagramas de forma integrada. Atualmente so contemplados os diagramas de casos de uso, classes, objetos, estados, atividades, sequncia, colaborao, componentes e implantao. Alm disso, a OODE permite a exportao e importao de modelos no formato XMI (formato XML padro para intercmbio de modelos UML), criando compatibilidade com ferramentas externas. A ferramenta encontra-se em fase de aperfeioamento e testes.
ODE possui hoje uma grande gama de ferramentas capazes de apoiar, de forma integrada, vrias atividades do desenvolvimento de software. Diversas delas esto prontas para serem utilizadas em projetos reais, tanto que j apiam a realizao de alguns projetos acadmicos. Com o intuito de atender no s aos interesses de pesquisa, mas tambm aos de mercado, o LabES dispem-se a estabelecer parcerias com organizaes de software. No contexto de uma parceria realizada entre o LabES e uma empresa de desenvolvimento de software capixaba, uma primeira verso de ODE foi implantada na organizao em outubro de 2004, visando apontar oportunidades de melhoria no ambiente como um todo tomando por base situaes reais da organizao. Com um primeiro feedback obtido, algumas melhorias foram realizadas e uma segunda verso foi liberada em fevereiro de 2005.
[1] [2] [3] HARRISON, W., OSSHER, H., TARR, P. Software Engineering Tools and Environments: A Roadmap, In: Proc. of The Future of Software Engineering, ICSE2000, Limerick, Ireland, 2000. PRESSMAN, R.S. Software Engineering: A Practitioner's Approach, 5th Edition, New York: McGraw-Hill, 2001. FALBO, R.A. Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software. Tese de Doutorado, COPPE/UFRJ, Rio de Janeiro, 1998.
3.9 LEITURA RECOMENDADA

PRESSMAN, Roger. Engenharia de software. 2006. McGraw Hill. Captulo 2 Processo: uma viso genrica; Captulo 3 Modelos Prescritivos de Processo; Captulo 4 Desenvolvimento gil; SOMMERVILLE, Ian. Engenharia de software. 2007. Processo de Software; Pearson Education. Captulo 4
PDUA FILHO, Wilson. Engenharia de software: fundamentos, Mtodos e Padres. 2009. LTC. Captulo 5: Processos de Software; BERTOLLO, Gleidson. Dissertao de Mestrado. Definio de processos em um ambiente de desenvolvimento de software. UFES. 2006. Notas de Aula Engenharia de Software, prof. Ricardo Falbo. http://www.inf.ufes.br/%7Efalbo/download/aulas/es-g/2006-2/NotasDeAula.pdf; Link:
Ambiente ODE, Laboratrio de Software, UFES. Link: http://www.inf.ufes.br/~labes/ode/.

mariateixeira-EC - Engenharia de Software - Conteúdo 3.2011.2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

mariateixeira-EC - Engenharia de Software - Conteúdo 3.2011.2

Enviado por

Direitos autorais:

Formatos disponíveis

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 29

3 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

3.1 PANORAMA SOBRE PROCESSO DE SOFTWARE

3.2 O QUE PROCESSO?

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 30

3.3 ATIVIDADES TPICAS DO PROCESSO DE SOFTWARE

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 31

3.4 CICLO DE VIDA DE SOFTWARE

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 32

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 33

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 34

3.5 MODELOS DE PROCESSO DE SOFTWARE

3.5.1 SELECIONANDO UM MODELO DE PROCESSO

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 35

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 36

3.5.3 PANORAMA SOBRE MODELOS PRESCRITIVOS DE PROCESSO

3.5.4 CODE AND FIX (CONSTRI E CONSERTA)

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 37

3.5.5 CLSSICO / EM CASCATA

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 38

Atividades do Ciclo de Vida Clssico

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 39

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 40

3.5.7 RAD (RAPID APPLICATION DEVELOPMENT)

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 41

3.5.8 MODELOS EVOLUCIONRIOS

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 42

Incio Fim Engenharia do Produto

Avaliao do Prottipo pelo Cliente

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 43

Este modelo classificado como sendo um Modelo Prescritivo de Processo, e evolucionrio.

Anlise dos Riscos

Deciso de Prosseguir ou no Na direo de um sistema concluido

Avaliao do cliente Avaliao do Cliente Engenharia

Prottipo de Software inicial

Prottipo de nvel seguinte Sistema construido pela engenharia

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 44

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 45

Um exemplo de uma rede de atividades pode ser como o da figura a seguir.

CEUNES / UFES Matria: O Processo de Desenvolvimento de Software

Disciplina: Engenharia de Software Pgina: 46

none Modeling act ivit y

represent s t he st at e of a sof t ware engineering activit y or task

Await ing changes

Under review Under revision Baselined

3.5.9 DESENVOLVIMENTO BASEADO EM COMPONENTES