Processos de Software

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO Processos de Software por LISANDRA VIELMO MANZONI Exame de Qualificação Prof. Dr. Roberto Tom Price Orientador Porto Alegre, Março de 2003.

2 2 Sumário LISTA DE FIGURAS...4 LISTA DE TABELAS...5 RESUMO INTRODUÇÃO PROCESSOS DE SOFTWARE EVOLUÇÃO DE PROCESSOS DE SOFTWARE Ciclos de Vida Metodologias Estruturadas Metodologias Orientadas a Objetos Processos de Software MODELOS DE CICLO DE VIDA DE SOFTWARE Modelo Cascata Modelo Espiral Modelo Paralelo/Recursivo Prototipação METODOLOGIAS ORIENTADAS A OBJETOS Object Modeling Technique - OMT Método Booch Object-Oriented Software Engineering (OOSE) Unified Modeling Language (UML) Comparando entre UML, OMT, OOSE e o Método Booch Processo e Modelos Recomendados por Larman AVALIAÇÃO DE PROCESSOS DE SOFTWARE ISO ISO/IEC Capability Maturity Model Capability Maturity Model Integration (CMMI) PROCESSOS DIRIGIDOS A PLANOS RATIONAL UNIFIED PROCESS (RUP) Melhores Práticas Ciclo de Vida do Processo Unificado Um Processo Integrado Disciplinas OPEN Criando um processo Ciclo de Vida de OPEN Arquitetura de OPEN Tarefas e Técnicas Atividades de OPEN Tarefas COMPARAÇÕES OPEN E RUP FLEXIBILIDADE DE PROCESSOS...61

3 3 4.2 TERMINOLOGIA, CONCEITOS E EXTENSÃO DO CICLO DE VIDA META-MODELO DE PROCESSO SUPORTE AO GERENCIAMENTO DE PROJETO Comparação com PMBOK OUTRAS CARACTERÍSTICAS PROCESSOS ÁGEIS PRINCÍPIOS BÁSICOS AGILE SOFTWARE MANIFESTO Finalidade do manifesto Princípios do Manifesto EXEMPLOS DE METODOLOGIAS SCRUM Rápido Tour em Scrum Abordagem Empírica EXTREME PROGRAMMING Quatro Valores de XP: Cinco Princípios de XP Doze Práticas de XP FEATURE DRIVEN DEVELOPMENT Best Practices Processos FDD ADAPTATIVE SOFTWARE DEVELOPMENT PAPERS The Decision is in: Agile versus Heavy Methodologies Get Ready for Agile Methods with care CONCLUSÃO PROCESSOS PLANEJADOS E ÁGEIS USAR PROCESSOS PLANEJADOS OU ÁGEIS?...91 BIBLIOGRAFIA...93

4 4 Lista de Figuras Figura Ciclo de Vida Clássico...13 Figura Modelo Espiral...14 Figura Prototipação...16 Figura Ciclo de Desenvolvimento Iterativo de Larman...22 Figura Avaliação de Processo de Software segundo ISO Figura Níveis de Maturidade do CMM...28 Figura Estrutura do CMM...29 Figura Componentes do Modelo CMMI Contínuo...31 Figura Componentes do Modelo CMMI Definido...32 Figura Representação Contínua...33 Figura Representação por Estágios...34 Figura Estrutura do Processo Duas Dimensões...38 Figura 3.2 Conceitos Básicos do Processo Unificado...43 Figura Estrutura do Framework de Processo OPEN...46 Figura Componentes Essenciais do OPF...46 Figura Suporte do Modelo de Ciclo de Vida para o Processo sob Construção...48 Figura Estágios de Gerenciamento de Projetos na Fase de Construção...48 Figura Meta-modelo de Estágios de OPEN...49 Figura Ciclo de Vida Dirigido a Contratos...51 Figura Rotas de Criação de Processos Específicos para Organização...62 Figura Exemplo de Instância de Processo OPEN...63 Figura Resumo do Meta-modelo do Framework OPEN...65 Figura Meta-modelo RUP...65 Figura Resumo Scrum...76 Figura Processos FDD...81 Figura Espectro de Planejamento...85 Figura Perfil RE de exposição a riscos...87 Figura Perfis de Exposição a Riscos de Companhias Ágeis e Dirigidas a Planos...88

5 5 Lista de Tabelas Tabela Relação entre Tarefas e Técnicas...50 Tabela Mapeamento entre Terminologia OPEN e RUP...63 Tabela Mapeamento entre Atividades e Estágios de OPEN e Fases de RUP...64 Tabela Áreas de Conhecimento do PMBOK...67 Tabela Avaliando RUP e OPEN em Relação ao PMBOK...68 Tabela Distribuição do Uso de Métodos ágeis...84 Tabela Resumo das Características de Processos Ágeis e Dirigidos a Planos...86

6 6 Resumo Esse trabalho descreve assuntos relevantes relacionados ao tema processo de software, enfatizando os processos atuais. Os processos atuais podem ser divididos em dois grupos: processos dirigidos a planos e processos ágeis. Inicialmente é descrita a evolução dos processos de software, desde os primeiros modelos, considerados modelos de ciclo de vida, passando por notações e metodologias de desenvolvimento, até os processos de software atuais, os quais possuem preocupações com gerência de projetos, gerência de mudanças, ferramentas, pessoas e demais aspectos de uma organização. A ênfase do trabalho é nos processos de desenvolvimento atuais, também chamados de processos de terceira geração. Os processos atuais se dividem, basicamente, em dois grupos, os processos dirigidos a planos e os processos ágeis. Processos dirigidos a planos, também chamados de metodologias heavyweight, são bastante formais e burocráticos, enfatizando uma grande quantidade de planos e documentação. Os processos ágeis, também chamados de metodologias lightweight, buscam na comunicação e espírito de equipe uma forma de evitar a burocracia e uma grande quantidade de documentos desenvolvidos. Como exemplo de métodos dirigidos a planos, são descritos o Rational Unified Process (RUP) e o Object-oriented Process, Environment and Notation (OPEN). Esses processos são comparados quanto à flexibilidade, meta-modelo, ciclo de vida, terminologia e outras características. Essa comparação foi realizada por outros autores. Os métodos ágeis descritos no trabalho são Extremme Programming (XP), Scrum e Feature Driven Development (FDD). XP é o representante dos métodos ágeis mais conhecido e mais utilizado atualmente. FDD é o processo que se aproxima mais de processos planejados. Ao final do trabalho, é descrita uma comparação entre os métodos ágeis e os métodos dirigidos a planos apresentados nesse trabalho, e uma análise do tipo de projeto que cada um desses métodos é melhor aplicável.

7 7 1. Introdução Processos de desenvolvimento de software tradicionais, também chamados de metodologias heavyweight, têm como objetivo tornar o desenvolvimento de software mais previsível e mais eficiente. Esses processos são bastante detalhados, formais, e enfatizam fortemente o planejamento. Exemplos dessa categoria de processo incluem: Rational Unified Process e Object-Oriented Process, Environment and Notation (OPEN). Nos últimos anos, têm surgido novas metodologias de desenvolvimento de software, são os chamados métodos ágeis, ou metodologias lightweight. Métodos ágeis enfatizam a agilidade e time-to-market, mas são altamente disciplinados. Esses novos métodos tentam balancear nenhum processo e muito processo, provendo apenas um processo suficiente para obter o resultado esperado. Como exemplos cita-se: Extreme Programming, SCRUM, Feature Driven Development, Crystal e Adaptative Software Development. Os métodos ágeis são menos orientados a documentação, geralmente enfatizando uma pequena quantidade de documentação para uma determinada tarefa, e são mais orientados a código [FOW 2002]. A avaliação dos processos de software é uma prática já executada por várias empresas e cada vez mais necessária. A organização pode utilizar um modelo de avaliação para classificar o processo de desenvolvimento de acordo com níveis de maturidade ou capacitação, e então estabelecer prioridades de melhoria. Esse trabalho tem como objetivo abordar o tema processo de software, incluindo modelos de processo, métodos de avaliação de processos e um novo tipo de processo que está surgindo chamado de Métodos Ágeis. O capítulo 2 descreve a situação atual em termos de processos de software e modelos de avaliação de processos. Na seção 2.1 são descritas as gerações de processos de software. Na seção 2.2 são descritos brevemente alguns modelos de ciclo de vida como o Modelo Espiral, Modelo Cascata, Prototipação, Modelo Paralelo/Recursivo. Na seção 2.3 são descritas algumas metodologias orientadas a objetos como: Object Modeling Technique (OMT), Método Booch, Object-Oriented Software Engineering (OOSE), Unified Modeling Language (UML) e o Processo Recomendado por Larman. A seção 2.4 resume alguns modelos de avaliação de processos, como as normas ISO e a ISO/IEC e os modelos CMM e o CMMI. No capítulo 3 são descritos exemplos de processos dirigidos a planos. Na seção 3.1 é descrito o Processo Unificado Rational, em termos de suas disciplinas, atividades, trabalhadores e artefatos. Na seção 3.2 é descrito o Object-oriented Process, Environment and Notation (OPEN). OPEN é um processo de domínio público, orientado a objetos, mantido pelo OPEN Consortion. Neste capítulo é descrita a arquitetura desse processo. O capítulo 4 mostra uma comparação entre o RUP e o OPEN quanto a flexibilidade, meta-modelo de processo, terminologia e ciclo de vida, suporte à gerência de projetos e outras características. No capítulo 5 é conceituado um novo tipo de processo que está surgindo, chamado de métodos ágeis. Esses métodos se propõem a ser menos burocrático que as metodologias convencionais, focando principalmente na codificação. No capítulo 6 são mostrados alguns exemplos de métodos ágeis, tais como Scrum, Extremme Programming (XP) e Feature Driven Development (FDD).

8 No capítulo 7 são comparados os processos dirigidos a planos e os processos ágeis, identificando as semelhanças e as diferenças entre esses processos e onde métodos ágeis são melhor aplicáveis que métodos planejados e vice-versa. 8

9 9 2. Processos de Software O processo de software provê um amplo e compreensível conceito para organizar os diferentes fatores e assuntos relacionados às atividades de desenvolvimento de software [FUG 2000]. O processo de software pode ser definido como o conjunto coerente de políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que são necessários para conceber, desenvolver, implantar e manter um produto de software. Então, o processo de software explora os seguintes conceitos [FUG 2000]: Tecnologia de desenvolvimento de software: ferramentas, infra-estrutura e ambientes; e ferramentas de suporte [HEN 2001]. Métodos e técnicas de desenvolvimento de software (metodologia): guia de como usar as tecnologias e acompanhar as atividades; Comportamento Organizacional: organização e pessoas. Diretamente relacionada com o gerenciamento das pessoas que trabalham no projeto [HEN 2001]. Pode também envolver marketing e economia, definindo o contexto onde o produto deve ser vendido, configurações específicas para usuário, etc. In [HUL 2002], processo é definido como: Processo é uma série de ações ou passos executados em ordem para alcançar um fim particular. Método é uma forma particular de procedimento para acompanhar ou abordar algo, de preferência deve ser sistemático e estabelecido. Metodologia é um sistema de métodos usados em uma área de estudo particular. O desenvolvimento de software pode ser descrito como consistindo de métodos (atividades executadas por engenheiros de software para desenvolver diagramas de casos de uso, diagramas de transição de estados, etc.), os quais quando referenciados juntos podem ser chamados de metodologia. A maneira como as metodologias são usadas é, portanto, limitada pela escolha do processo. Jacobson [RAT 2001], afirma que um processo define quem está fazendo o que, como e quando para alcançar um certo objetivo, e que um processo efetivo provê guias para o desenvolvimento eficiente de software de qualidade. Zahran descreve três aspectos do processo, que são [ZAH 98]: i. Definição do processo: especifica as atividades e procedimentos a serem executadas no processo. ii. Conhecimento do processo: o conhecimento do processo deve dirigir o comportamento e as atividades daqueles que executam o processo. iii. Resultados do processo: manifestado pelos produtos produzidos como resultado de execução das atividades do processo. Um processo de software definido possibilita que os desenvolvedores usem uma linguagem comum para se comunicarem, elaborem documentos similares, usem técnicas similares na resolução de problemas, adotem estilos de projeto e codificação que sejam prontamente entendidos e fáceis de transmitir entre membros da equipe e gerenciamento.

10 Produtos de trabalho são padronizados e mais fáceis de serem compreendidos e avaliados. Qualidade do processo pode contribuir para a qualidade do produto. O ciclo de vida do software (cascata, incremental, prototipação, etc,) define os diferentes estágios no tempo de vida de um produto de software, tais como: requisitos, análise e especificação, desenho (design), desenvolvimento, verificação e validação, implantação, operação, manutenção e desativação. O ciclo de vida define os princípios e guias de acordo com os quais esses estágios devem ser executados. Em geral, o ciclo de vida define o esqueleto e a filosofia de acordo com os quais o processo de software deve ser executado [FUG 2000]. As estratégias para desenvolvimento podem ser classificadas em: desenvolvimento iterativo, desenvolvimento incremental e prototipação [GOL 96]. O desenvolvimento iterativo permite o retrabalho controlado de partes de um sistema para remover erros ou fazer melhorias com base no retorno do usuário [GOL 96]. No modelo iterativo os passos não precisam ser realizados seqüencialmente, a ordem é a mais oportuna baseada na situação atual. Essa abordagem é semelhante a montagem de um quebra-cabeça, onde as peças são montadas na ordem em que são descobertas [GOL 96]. O desenvolvimento incremental é uma estratégia para progredir em pequenos passos, obtendo resultados tangíveis o mais cedo possível. A abordagem incremental requer que o problema seja particionado em vários subproblemas e então cada problema seja desenvolvido em um incremento. Quando cada partição é concluída deve ser testada e integrada com as demais partições já desenvolvidas do sistema. No final de cada estágio, o sistema parcialmente completo pode ser avaliado para influenciar o desenvolvimento futuro [GOL 96]. O termo iterativo e incremental são freqüentemente usados com o mesmo sentido quando se descreve modelos de processo. Porém, eles são estratégias de desenvolvimento distintas e independentes. O desenvolvimento iterativo suporta o retrabalho de partes do sistema. O desenvolvimento incremental permite que o sistema seja particionado e desenvolvido em diferentes tempos. O desenvolvimento iterativo e incremental pode ser usado separadamente ou junto [GOL 96]. A prototipação busca informações necessárias ao sistema a ser desenvolvido. Prototipação pode ajudar na redução de erros em definir os requisitos ou projetar a arquitetura. Um protótipo é uma versão preliminar do sistema, intencionalmente incompleta ou proporcionalmente reduzida [GOL 96] Evolução de Processos de Software A seguir será descrita uma evolução cronológica dos processos de software, desde modelos de ciclo de vida até os processos existentes hoje Ciclos de Vida A solução inicial proposta nos anos 60 para os problemas de software foi o conceito de ciclo de vida de software. O ciclo de vida define a vida padrão de um produto de software desde a sua concepção até a implantação e manutenção. Isto significa que o processo de desenvolvimento é decomposto em uma seqüência pré-definida de fases, e cada fase é estruturada como um conjunto de atividades. Cada fase recebe entradas da fase anterior e provê saída para a próxima fase. A escolha do ciclo de vida padroniza tanto a decomposição do processo em fases, como os artefatos (documentos) que fluem entre as fases [CUG 98].

11 As falham dos modelos de ciclo de vida ocorrem devido à exigência de padronização do processo de software - isto é, seguir uma seqüência rígida de passos, e de que o conhecimento total sobre o projeto seja conhecido no início do projeto. Exemplos de ciclos de vida incluem Modelo Cascata e suas variações, Modelo Espiral, Prototipação, etc Metodologias Estruturadas Metodologias de software foram criadas com o objetivo de guiar o desenvolvimento de software com base em experiências obtidas em projetos bem-sucedidos. As metodologias forneciam um conjunto de notações para serem usadas na especificação do software, e um conjunto de guias detalhados e recomendações em como as notações poderiam ser usadas desde as fases iniciais até a codificação. As metodologias requeriam uma grande quantidade de papel, e não existiam ferramentas disponíveis para auxiliar na criação de modelos. Desenvolvedores prestavam muita atenção nos modelos e notação e negligenciavam no conteúdo [CUG 98]. Exemplos incluem: Projeto Estruturado: proposto por Yourdon e Constantine (1978) - especificação do sistema em módulos [YOU 78]. Análise Estruturada Moderna: proposto por Yourdon (1989) - diagrama de fluxo de dados e lista de eventos [YOU 89]. Jackson Structured Programming(JSP) [JAK 75] que evolui para Jackson System Development (JSD): proposto por Jackson [JAK 83]. Engenharia da Informação: proposto por James Martin (1981) - baseada nas informações e ênfase no modelo de dados [MAR 81] Metodologias Orientadas a Objetos As primeiras metodologias orientadas a objetos foram baseadas nas metodologias estruturadas existentes anteriormente. Esses modelos têm como base os métodos estruturais ou modelagem de dados relacional. Exemplos incluem [KIV 2000]: Object Modeling Technique (OMT): proposto por Rumbaugh et al. (1991) - bastante referenciado [RUM 91]. Object-Oriented Software Engineering (OOSE): proposto por Jacobson et al. (1992) - Use Cases [JAC 92] Method Booch: proposto por Booch (1991) [BOO 94] Os métodos orientados a objetos foram usados por muitas companhias, e experiências foram obtidas. Os modelos também foram melhorados pela inclusão de idéias de diferentes modelos e experiência prática. A importância da arquitetura cliente/servidor como parte do desenvolvimento de aplicações orientadas a objetos foi também notada [KIV 2000]. Fusion: proposta por Coleman (1994) SOMA: proposta por Graham (1995) MOSES: Henderson-Sellers and Edwards (1994) Vários modelos compreensíveis foram introduzidos neste período. Métodos orientados a objetos foram usados em projetos na indústria e forneceram feedback para os 11

12 desenvolvedores de modelos. Pesquisadores e práticos juntaram suas forças no fim deste período para criar modelos de processos mais maduros [KIV 2000]. Em 1997, foi criada a UML como a unificação das três maiores metodologias de desenvolvimento existentes, a OMT, proposta por James Rumbaugh; o Método Booch, proposto por Grady Booch; e a OOSE de Ivar Jacobson, e de outros métodos que se destacavam [BOO 98]. Surgiram várias outras metodologias baseadas na notação UML Processos de Software As metodologias criadas até 1997 não se preocupavam com elementos do processo ou gerenciamento de projetos, basicamente consistiam de coleções de técnicas de modelagem com algumas dicas no desenvolvimento mais amplo do software [HEN 2000]. A idéia acima dos processos de software é descrever uma linguagem de modelagem com semântica e notação estritas, e também oferecer gerenciamento de projetos, preocupação com ferramentas e pessoas, e conselhos de qualidade. Outra preocupação dos processos de software é a arquitetura da aplicação, pois as aplicações desenvolvidas são cada vez mais complexas, com base de dados distribuídas, e erros arquiteturais podem ser fatais para um projeto. Processo Unificado/Rational Unified Process: utiliza como linguagem de modelagem a UML. Esse processo foi proposto pela Rational e elaborado por: Rumbaugh, Jacobson and Booch (1999) [RAT 2001][JAC 98] OPEN: proposto por Henderson-Sellers, Firesmith and Graham - Fusão das metodologias MOSES, SOMA e Firesmith [HEN 97] Modelos de Ciclo de Vida de Software Muitos processos de software existem, como o Modelo Espiral [BOE 88], Modelo Cascata [BOE 81], Modelo Paralelo/Recursivo [BER 93], Prototipação [PRE95], Processo Unificado Rational [RAT 99][RAT 2001] e o Open Process Framework (OPEN) [HEN 99][HEN 2000]. Os dois últimos são mais específicos para processos orientados a objetos [HEN 99]. Cada modelo de processo foca em diferentes funcionalidades e pode ser melhor adaptado para certos tipos de projetos de software. Esta seção descreve resumidamente os modelos de ciclo de vida como: Cascata [BOE 81], Modelo Espiral [BOE 88], Modelo Paralelo/Recursivo [BER 93], Prototipação e o Processo Recomendado por Larman [LAR 2000][LAR 2000]. O Processo Unificado Rational e o OPEN estão descritos em maiores detalhes nos capítulos 3 e 3.2, respectivamente Modelo Cascata O Modelo Cascata (Waterfall Model) apresenta o ciclo de vida clássico da engenharia de software. O paradigma do Modelo Cascata, também chamado de Ciclo de Vida Clássico, requer uma abordagem sistemática, seqüencial ao desenvolvimento de software, que se inicia no nível do sistema e avança ao longo da análise, projeto, codificação, teste e manutenção. O Modelo Cascata se baseia nas seguintes premissas [GOL 96]: - Metas são melhor alcançadas por focar em marcos bem-definidos e documentados dividindo o desenvolvimento em estágios seqüenciais;

13 - Documentos técnicos são entendidos por usuários não-técnicos e gerentes, e esses participantes não-técnicos podem comunicar-se efetivamente com analistas; - Todos os detalhes sobre requisitos e funções podem ser conhecidos antes do desenvolvimento do software, e esses detalhes permanecem estáveis através do desenvolvimento; - Teste e avaliação podem ser eficientemente executadas no final do desenvolvimento. Modelado em função do ciclo de vida da engenharia convencional, o Modelo Cascata abrange as seguintes atividades [PRE 95]: Análise e Engenharia de Sistemas: envolve o estabelecimento dos requisitos para todos os elementos do sistema e prossegue com a atribuição de um subconjunto desses requisitos ao software. Análise de Requisitos de Software: o processo de coleta dos requisitos é intensificado e concentrado especificamente ao software. Projeto: o projeto do software se concentra em quatro atributos distintos do programa, que são: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização da interface. Codificação: traduzir o projeto para uma forma legível pelo computador. Teste: devem ser realizados testes para garantir que todas as instruções internas tenham sido testadas, para descobrir erros e garantir que cada entrada produz o resultado esperado. Manutenção: mudanças no software depois da entrega ao cliente. Essas mudanças podem ser causadas por erros encontrados ou por novas funcionalidades necessárias ao sistema. 13 Engenharia de Sistemas Análise de Requisitos Projeto Codificação Teste Manutenção Figura Ciclo de Vida Clássico O ciclo de vida clássico vem sofrendo várias críticas nas últimas décadas. Os principais problemas do Modelo em Cascata são [PRE 95]:

14 14 - Os projetos raramente seguem um fluxo seqüencial. Alguma iteração sempre ocorre e traz problemas no uso deste paradigma; - É difícil definir todos os requisitos no início do projeto, e os requisitos podem mudar ao longo do tempo. - O produto somente será entregue no final de todo o desenvolvimento Modelo Espiral Boehm modificou o Modelo Cascata, produzindo uma série de espirais que explicitamente incluem prototipação [GOL 96]. O Modelo Espiral [BOE 88] é uma estratégia para reduzir riscos. Boehm o descreveu como dirigido a riscos, por causa de sua ênfase em ciclos de trabalho, onde antes de iniciar o próximo ciclo é realizada uma análise de riscos. Cada ciclo inicia com a identificação dos objetivos para o ciclo, maneiras alternativas de acompanhar os objetivos, restrições associadas a cada alternativa, e uma avaliação das alternativas. Quando é identificada incerteza, várias técnicas são usadas para reduzir risco na escolha entre as alternativas. Cada ciclo do Modelo Espiral finaliza com a revisão que discute os resultados atuais e o plano para o próximo ciclo obtendo o engajamento dos membros da equipe no próximo ciclo. A revisão pode determinar que os desenvolvimentos futuros não encontrarão os objetos e metas iniciais do projeto, e então a espiral finaliza. O Modelo Espiral define quatro atividades importantes, que são [PRE 95]: Planejamento: determinação dos objetivos, das alternativas e das restrições. Análise dos riscos: análise de alternativas e identificação/resolução de problemas. Engenharia: desenvolvimento do produto no próximo nível. Avaliação pelo cliente: avaliação dos resultados da engenharia. Figura Modelo Espiral O Modelo Espiral se baseia nas seguintes premissas [GOL 96]: - Uma atividade inicia com um entendimento dos objetivos e riscos envolvidos;

15 - Com base na avaliação das alternativas de solução, usar a ferramenta que melhor reduz o risco; - Toda a equipe deve ser envolvida na revisão ao final de cada ciclo; - O desenvolvimento pode prosseguir em incrementos em cada estágio. O Modelo Espiral usa a abordagem evolutiva para desenvolvimento, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa. Este modelo também usa a prototipação como forma de reduzir riscos, e permite ao desenvolvedor aplicar a prototipação em qualquer etapa na evolução do produto. O Modelo Espiral mantém a abordagem de passos sistemáticos sugeridas pelo ciclo de vida clássico, mas incorpora-a em uma estrutura iterativa, refletindo de maneira mais realista o mundo real. Os riscos são considerados em todas as etapas do projeto, reduzindo a probabilidade de eles virem a ocorrer [PRE 95] Modelo Paralelo/Recursivo Modelo Paralelo/Recursivo reconhece que durante o desenvolvimento de software, os analistas e projetistas trabalham em alguns requisitos e deixam outros para mais tarde [GOL 96]. Conforme o proponente principal do modelo [BER 93], a abordagem básica é decompor o problema sistematicamente em componentes independentes, então reaplicar o processo de decomposição em cada desses componentes futuramente. Este processo pode ser aplicado para cada componente simultaneamente (a parte paralela). Reaplicação continua até que algum critério de conclusão seja encontrado. Decomposição tem também a sua função. Grandes componentes são decompostos; novos componentes são criados como decomposição dos componentes existentes. O processo que será aplicado - no todo ou em parte - para cada componente é: análise, seguida de projeto, implementação e teste. Este modelo tem sido freqüentemente descrito como: analyse a little, design a little, implement a little, test a little [GOL 96]. Para o Modelo Recursivo/Paralelo ser efetivo, os componentes devem ser independentes entre si - normalmente é usado em tecnologia orientada a objetos. Já a decomposição funcional - por definição - conduz a descrições de funções que são intimamente acopladas. Subfunções existem apenas para suporte a função que a chama [GOL 96]. As premissas do Modelo Paralelo/Recursivo são [GOL 96]: - Desenvolvimento deve ter como foco o trabalho em componentes paralelos e independentes; - Sistema deve ser projetado como uma composição de componentes criados independentemente Prototipação A prototipação é um processo que capacita o desenvolvedor a criar um modelo do software que será implementado. O modelo pode assumir uma das três formas: um protótipo em papel ou de telas, onde é retratada a interação homem-máquina, capacitando o usuário a entender as interações que ocorrerão; ou um protótipo que implementa um subconjunto de alguma função do sistema; ou um programa existente que executa parte ou toda função desejada, mas que tem funcionalidades que precisam ser melhoradas [PRE 95]. 15

16 O modelo de prototipação inicia com a coleta dos requisitos, onde o cliente define, junto ao desenvolvedor, os requisitos necessários ao software. Após essa definição, ocorre a elaboração de um projeto rápido, onde são representados os aspectos do software que serão visíveis aos usuários. O projeto rápido leva a construção de um protótipo que é avaliado pelo cliente/usuário, e é usado para refinar os requisitos para o software a ser desenvolvido. Baseado no protótipo o cliente e o desenvolvedor discutem as necessidades do cliente, capacitando o desenvolvedor a entender melhor os requisitos do sistema pelo refinamento do protótipo [PRE 95]. Idealmente o protótipo serve como um mecanismo para identificar os requisitos de software. Brooks [BRO 75] recomenda que o protótipo seja descartado, pois normalmente o protótipo é desenvolvido rapidamente sem preocupações com qualidade e manutenibilidade, então não pode se tornar um produto. 16 Fim Início Coleta e Refinamento dos Requisitos Engenharia do Produto Projeto Rápido Refinamento do Protótipo Construção do Protótipo Avaliação do Protótipo pelo Cliente Figura Prototipação 2.3 Metodologias Orientadas a Objetos Nessa seção serão descritas algumas metodologias orientadas a objetos que serviram de base aos processos atuais, tais como: Object Modeling Technique (OMT), Método Booch, Object-Oriented Software Engineering (OOSE), Unified Modeling Language (UML) e Processo e Modelos Recomendados por Larman Object Modeling Technique - OMT A metodologia OMT, proposta por Rumbaugh em 1993, consiste em se construir um modelo baseado em objetos do domínio da aplicação e adicionar à ele detalhes de implementação, de modo que o mesmo modelo possa evoluir da fase de análise, para o projeto e daí para a implementação, cobrindo todas as fases do ciclo de vida do sistema. O propósito da análise é definir e entender o problema e o domínio da aplicação. O projeto gera, sobre o resultado da análise, uma estrutura de alto-nível do sistema que servirá de base para a

17 implementação. A implementação, fase final do processo, é a tradução do projeto em código [RUM 91]. A metodologia OMT faz uso de três tipos de modelos para descrever um sistema: o modelo de objetos, que descreve os objetos do sistema e seus relacionamentos; o modelo dinâmico, que descreve as interações entre os objetos do sistema; e o modelo funcional, que descreve as transformações dos dados do sistema. Os modelos são aplicáveis durante todas as etapas do desenvolvimento e são adicionados a estes detalhes de implementação à medida que o desenvolvimento evolui [RUM 91]. Modelagem de Objetos Modelagem de objetos envolve a elaboração de diagramas de objetos, que oferecem uma notação gráfica formal para a modelagem de objetos e seus inter-relacionamentos. Os objetos permitem o entendimento do mundo real, pela representação de seus elementos, e visam fornecer uma base para a implementação da solução [RUM 91]. Modelagem Dinâmica O modelo dinâmico mostra o comportamento e mudanças do sistema e dos objetos em relação ao tempo. O modelo dinâmico é composto pelos eventos e estados de um sistema. Inicialmente, deve-se buscar os eventos (estímulos e respostas externamente visíveis). Depois estes eventos devem ser resumidos em seqüência de eventos para cada objeto, através do diagrama de estados. O diagrama de estados mostra os eventos que o objeto recebe e envia, juntamente com as ações que este executa [RUM 91]. O modelo dinâmico é uma coleção de diagramas de estados que interagem uns com os outros por intermédio de eventos compartilhados. Modelagem Funcional O modelo funcional descreve os cálculos executados em um sistema, mostra como os valores de saída de um processamento derivam dos valores de entrada, sem preocupações com a ordem em que os valores são processados. O modelo funcional consiste de múltiplos diagramas de fluxo de dados (DFD) que especificam o significado das operações e restrições. Um DFD contém processos que transformam dados, fluxos de dados que movimentam os dados, objetos atores que produzem e consomem dados, e objetos depósitos, que armazenam dados[rum 91] Método Booch Grady Booch desenvolveu o Método Booch, que cobre as fases de projeto e análise de sistemas orientados a objetos. Este método suporta o desenvolvimento incremental e iterativo de um sistema [BOO 94]. O método Booch define diferentes modelos para descrever seu sistema. O modelo lógico é representado na estrutura de classes e objetos. O diagrama de objetos mostra a interação entre as classes, e ajuda a entender o comportamento dinâmico do sistema [SCH93]. A arquitetura de módulos e processos descreve a alocação física das classes em módulos e processos [BOO 94]. Diagrama de classes Mostra a existência de classes e suas relações na visão lógica do sistema. Diagrama de objetos 17

18 Mostra a existência de objetos e suas relações na visão lógica do sistema, também descreve a execução de um cenário. Diagramas de transição de estados O diagrama de transição de estados é usado para mostrar o espaço de estados de uma determinada classe, os eventos (mensagens) que causam a transição de um estado para outro, e as ações que resultam de uma mudança de estados. Diagrama de módulos O diagrama de módulos mostra a alocação física das classes nos módulos. O padrão é alocar cada classe em um arquivo separado, caso seja necessário alocar várias classes em um arquivo, deve-se introduzir o diagrama de módulos. Diagramas de processos Mostra a alocação de processos em processadores na visão do sistema. Diagramas de interação Descreve a execução de um cenário, a troca de mensagens entre os objetos Object-Oriented Software Engineering (OOSE) A metodologia de desenvolvimento de sistemas orientados a objetos OOSE, foi desenvolvida por Ivar Jacobson. Essa metodologia abrange cinco modelos para a representação de um sistema de desenvolvimento, o Modelo de Requisitos, Análise, Projeto, Implementação e Testes. Estes modelos são criados seqüencialmente ao longo do processo de desenvolvimento do sistema, e descrevem os diferentes estágios do ciclo de vida em cascata. Um modelo é criado através da transformação do anterior, incorporando características do problema, em relação às necessidades de modelagem do estágio corrente de desenvolvimento [JAC 92]. Modelo de requisitos O modelo de requisitos tem o objetivo de delimitar a abrangência do sistema e definir os requisitos funcionais. Este modelo é composto de três submodelos, que são: o modelo de casos de uso, modelo do domínio e modelo de interfaces [JAC 92]. Modelo de casos de uso: os casos de uso são utilizados para definir a funcionalidade que o sistema fornece ao usuário. Um caso de uso representa uma forma de interação com o sistema, mostrando os atores, que são pessoas ou sistemas que interagem com o software que está sendo modelado. Um caso de uso deve possuir um nome e uma descrição. Modelo do domínio: identifica os objetos do mundo real, associa-se a estes uma descrição textual, e incorpora tipos de relacionamento entre os objetos comunicação e herança. Modelo de interfaces: este modelo é composto por um conjunto de gráficos que descrevem a forma que a aplicação será apresentada ao usuário, detalham o layout das telas. Modelo de Análise O modelo de análise se preocupa com a estrutura do sistema, e baseia-se na distribuição entre os objetos do comportamento especificado nos casos de uso, consiste de três tipos de objetos: objetos de interface, objetos entidades e objetos de controle [JAC 92].

19 Objetos de interface: permitem a comunicação entre os atores e o sistema, possui toda a funcionalidade especificada nos casos de uso que é dependente do ambiente onde se utilizará o sistema. Objetos entidade: modelam a informação que o sistema deve gerenciar ao longo do tempo, esta informação deve ser mantida mesmo após o término do caso de uso. Objetos de controle: em casos de uso muito complexos, existem determinados comportamentos que não podem ser atribuídos aos objetos de interface, nem aos objetos entidades, então esses comportamentos são atribuídos aos objetos de controle. Os objetos de controle servem para unir outros objetos formando um caso de uso. Alguns exemplos de funcionalidades atribuídas a objetos complexos: comportamento relativo às transações, seqüências específicas de um ou mais casos de uso, ou funcionalidade destinada a ocultar objetos entidades dos objetos de interface [JAC 92]. Modelo de Projeto O modelo de projeto é um refinamento do modelo de análise onde as características do ambiente de implementação são consideradas. O modelo de projeto é definido como um contexto que agrupa Diagramas de Blocos, Diagramas de Transições e Diagramas de Interação [JAC 92]. Diagrama de blocos: o modelo de projeto é formado por blocos (os objetos do projeto) que serão traduzidos em código fonte (blocos de implementação), este blocos correspondem a objetos do modelo de análise. As associações entre os blocos mostram os relacionamentos reais entre os objetos. Diagramas de transição: este diagrama especifica as operações associadas aos objetos. Um grafo de transições pode ser definido como uma nova classe de contexto, integrada por estados e transições. Diagrama de interação: é um documento (contexto) que relaciona um caso de uso, um conjunto de atores, um conjunto de objetos (que resolvem o caso de uso), um conjunto de mensagens (comunicação) e sinais. Modelo de Implementação Através do diagrama de blocos, a implementação fica simples. É aconselhável utilizar padrões de codificação, facilitando a compreensão do código gerado e a revisão por programadores que não estão envolvidos na implementação [JAC 92]. Modelo de Teste Inclui informações geradas pela atividade de teste. Vários tipos de teste podem ser usados, como teste de integração, unidade, regressão, operação e performance Unified Modeling Language (UML) A UML surgiu como uma tentativa de padronizar as linguagens de modelagem orientadas a objetos. A UML surgiu da unificação das três maiores metodologias de desenvolvimento existentes, a OMT, proposta por James Rumbaugh; o Método Booch, proposto por Grady Booch; e a OOSE de Ivar Jacobson, e de outros métodos que se destacavam [BOO 98]. A UML divide o desenvolvimento de um sistema em cinco fases: especificação de requisitos, análise, projeto, implementação e testes, e provê diagramas para serem aplicados 19

20 em todas as fases do desenvolvimento. Esses diagramas podem ser utilizados para modelar vários tipos de sistemas, desde software até processos organizacionais [BOO 98]. A UML suporta modelos estáticos, dinâmicos e funcionais. O modelo estático compreende os diagramas de classes e objetos; o modelo dinâmico é suportado pelos diagramas de estado, seqüência, colaboração e atividade; já o modelo funcional engloba os diagramas de casos de uso, componentes e implantação [BOO 98]. Diagrama de casos de uso: serve para representar a funcionalidade de um sistema mostrado através dos atores externos. Representa as interfaces do sistema com o mundo externo, as entidades externas que interagem com estes, e suas inter-relações. Diagrama de classes: mostra a estrutura estática de um modelo, as entidades que existem no contexto do problema, a estrutura interna destas, e as relações entre as entidades do modelo. Diagrama de objetos: mostra as instâncias de um sistema em um determinado momento. Através das classes definidas no diagrama de classes, os objetos são instanciados originando o diagrama de objetos. Diagrama de estados: mostra a seqüência de estados que um objeto pode passar durante seu ciclo de vida em reação a estímulos recebidos, junto com as reações e ações. Um diagrama de estados representa uma máquina de estados, um estado é uma condição durante a vida do objeto ou uma interação durante a qual este satisfaz alguma condição, executa alguma ação ou espera por algum evento. Diagrama de seqüência: mostra a colaboração dinâmica entre os vários objetos de um sistema. O mais importante aspecto deste diagrama é que a partir dele percebe-se a seqüência de mensagens enviadas entre os objetos. Diagrama de colaboração: mostra de maneira semelhante ao diagrama de seqüência, a colaboração dinâmica entre os objetos. No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos, são descritos os objetos com os seus relacionamentos. O diagrama de seqüência é melhor para representações em que o tempo é mais importante, e os de colaboração para representar o contexto do sistema. Diagrama de atividades: mostra o fluxo seqüencial das atividades, é normalmente utilizado para demonstrar as atividades executadas por uma operação específica do sistema. Diagrama de componentes: descreve os componentes de software e suas dependências, representando a estrutura do código gerado. Os componentes são a implementação na arquitetura física dos conceitos e da funcionalidade definidos na arquitetura lógica (classes, objetos e seus relacionamentos). Diagrama de implantação: mostra a arquitetura física entre os componentes de software e hardware do sistema. Este diagrama pode ser utilizado para demostrar como os componentes e objetos são roteados e movidos através de um sistema distribuído Comparando entre UML, OMT, OOSE e o Método Booch Analisando as técnicas de modelagem conclui-se que a OMT, a OOSE e a UML abrangem todas as etapas do ciclo de vida do software, já o método Booch engloba apenas a análise e o projeto do sistema. As metodologias OMT e Booch são centradas nos dados, já a OOSE e a UML são centradas no comportamento. 20

21 O método Booch é criticado por ser muito extenso e usar uma variedade de notações em seus diagramas. A notação UML tem características das outras três metodologias apresentadas, a seguir será descrita uma análise da origem dos diagramas da UML, com relação as metodologias apresentadas. Casos de Uso: tem origem nos diagramas de casos de uso da metodologia OOSE. Diagrama de Classes e de Objetos: todos os métodos apresentados apresentam diagrama de classe e/ou de objetos. Diagrama de interação: semelhante aos diagramas de interação do modelo OOSE, e Booch. Diagrama de estados: primeiramente foi utilizado por Rumbaugh, no OMT, e após por Booch, em seu método. Diagrama de componentes: semelhante aos diagramas de bloco do modelo OOSE, e aos diagrama de módulos do método Booch Processo e Modelos Recomendados por Larman Em [LAR 2000], Larman propõe uma descrição das melhores práticas, das atividades básicas e dos modelos comumente recomendados, num processo de desenvolvimento de sistemas orientados a objetos baseado numa abordagem iterativa e incremental, dirigida a casos de uso [LAR 2000]. Larman nomeou esse roteiro de Processo e Modelos Recomendados (PMR). As influências básicas sobre PMR incluem os modelos: Fusion [COL 94], Martin- Odell [MAR 95], Projeto Orientado por Responsabilidade [WIF 93], OOSE [JAC 92], OMT [RUM 91] e Booch [BOO 94]. Os passos do processo em um nível macro incluem [LAR 2000]: Planejar e elaborar: planejamento, definição de requisitos, construção de protótipos e assim por diante. Construir: a construção do sistema. Instalar: a implantação do sistema para uso. Um ciclo de desenvolvimento iterativo se baseia no aumento e no refinamento sucessivo de um sistema através de múltiplos ciclos de desenvolvimento de análise, de projeto, de implementação e de teste [LAR 2000]. O sistema cresce pelo acréscimo de novas funções em cada ciclo de desenvolvimento. Após uma fase preliminar de Planejar e Elaborar, o desenvolvimento continua numa fase de construção através de uma série de ciclos de desenvolvimento [LAR 2000]. Cada ciclo trata com um conjunto relativamente pequeno de requisitos, procedendo através da análise, do projeto, da construção e do teste. O sistema cresce incrementalmente à medida que cada ciclo é completado [LAR 2000]. O sistema cresce pelo acréscimo de novas funções em cada ciclo de desenvolvimento. Após uma fase preliminar de Planejar e Elaborar, o desenvolvimento continua numa fase Construir através de uma série de ciclos de desenvolvimento [LAR 2000].

22 Cada ciclo trata um conjunto relativamente pequeno de requisitos, procedendo através da análise, do projeto, da construção e do teste Figura 2.4. O sistema cresce, incrementalmente, à medida que cada ciclo é completado [LAR 2000]. A duração de cada ciclo de desenvolvimento deve ser de 2 semanas a 2 meses. Os ciclos de desenvolvimento são organizados por requisitos de casos de caso. 22 Figura Ciclo de Desenvolvimento Iterativo de Larman [LAR 2000] Fase Planejar e Elaborar A fase Planejar e Elaborar de um projeto inclui a concepção inicial, a investigação de alternativas, o planejamento, a especificação de requisitos e assim por diante. Os seguintes artefatos são gerados nessa fase [LAR 2000]: - Plano: cronograma, recursos, orçamento, etc. - Relatório de investigação preliminar: motivação, alternativas, necessidades de negócio. - Glossário: dicionário de termos. - Protótipo: - Casos de uso: - Diagramas de casos de uso: - Rascunho do modelo conceitual: Fase Construir A fase construir envolve repetidos ciclos de desenvolvimento, dentro dos quais o sistema é estendido. O objetivo final é um sistema de software em operação que atenda corretamente os requisitos. Na fase de análise são realizadas as seguintes atividades [LAR 2000]: - Definir casos de uso essenciais; - Refinar diagramas de casos de uso;

23 23 - Refinar o modelo conceitual; - Refinar glossário; - Definir diagramas de seqüência do sistema; - Definir contratos de operação; - Definir diagramas de estado; Na fase de projeto são realizadas as seguintes atividades: - Definir casos de uso reais; - Definir relatórios, interfaces de usuários e Story boards ; - Refinar a arquitetura do sistema; - Definir diagramas de interação; - Definir diagramas de classes de projeto; - Definir esquema do banco de dados. 2.4 Avaliação de Processos de Software Nos últimos anos, o interesse das organizações que desenvolvem software não tem sido somente no uso de modelos de processo de desenvolvimento de software, cada vez mais as organizações estão interessadas em avaliar e melhorar seus próprios processos. A prova deste interesse pode ser verificada pela quantidade de modelos de avaliação de processos encontrada na literatura [FIT 99][KRI 99], ilustrada pelo CMM [PAU 93][PAU 93a][KRI 99], Bootstrap [HAA 94], Trillium [BEL 94] e SQUID [BOJ 99] e os esforços de padronização como as normas ISO [ISO 91], ISO/IEC12207 [ISO 95] e ISO/IEC15504 [ISO 95a]. A qualidade de software é largamente determinada pela qualidade dos processos utilizados para seu desenvolvimento. Desde modo, a melhoria da qualidade de software é obtida pela melhoria da qualidade dos processos. Essa visão orientou a elaboração de modelos de definição, avaliação e melhoria de processos de software, tais como: Bootstrap: esquema derivado do Capability Maturity Model (CMM), para avaliação de organizações, desenvolvido pela Comunidade Européia [HAA 94]. Trillium: esquema derivado do CMM e outros modelos, para avaliação de organizações, desenvolvido no Canadá [BEL 94]. Software Quality In the Development (SQUID): é um consórcio de empresas e institutos da Europa. Está baseado nos conceitos e definições das normas ISO 9001, ISO/IEC 9126 e ISO/IEC [BOJ 99]. ISO/IEC Processos de Ciclo de Vida de Software: norma de definição dos processos do ciclo de vida do software [ISO 95]. As normas ISO e ISO/IEC e os modelos CMM e CMMI também propõem a melhoria dos processos de desenvolvimento e serão descritos brevemente nas próximas seções.

24 ISO A ISO é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software. Para cada item da ISO 9001 existe um correspondente na ISO que o detalha e o especifica ao software [ISO 95]. As diretrizes propostas na ISO cobrem questões como o entendimento comum entre as partes (contratante e contratado) de requisitos funcionais e uso de metodologias consistentes para o desenvolvimento de software e gerenciamento de projeto como um todo, da concepção até a manutenção [ISO 95]. Essa norma é dividida em três partes principais, que são: - Estrutura, descreve aspectos organizacionais, relacionados ao sistema de qualidade; - Atividades do ciclo de vida que descrevem as atividades de desenvolvimento de software; - Atividades de suporte que descrevem as atividades que apóiam as atividades do ciclo de vida de desenvolvimento ISO/IEC Em junho de 1991, o comitê de engenharia de software da ISO, aprovou a realização de um período de estudos para analisar as necessidades e os requisitos de um padrão para avaliação do processo de software. Este estudo apontou um consenso internacional sobre a necessidade de um padrão para avaliação do processo de software e a importância de se implementar melhorias no processo de desenvolvimento [ISO 95a]. Em 1993, foi criado o projeto SPICE (Software Process Improvement and Capability Determination), com o objetivo de gerar normas que orientem a avaliação do processo de software, visando a melhoria contínua do processo e a determinação de sua capacitação. Baseia-se nas melhores características de outros modelos de avaliação de processos existentes, como: CMM, Trillium, Software Tecnology Diagnostic (STD), Bootstrap, sendo o CMM o que apresenta mais influência [ISO 95a]. A norma ISO/IEC 15504, também chamada de SPICE, pode ser utilizada por organizações envolvidas em planejar, gerenciar, monitorar, controlar e melhorar a aquisição, fornecimento, desenvolvimento, operação, evolução e suporte de software. De acordo com a visão proposta da ISO (Figura 2.5), a avaliação de processos de software tem como objetivos [ISO 95a]: - Entender o estado dos processos de uma organização, buscando a melhoria destes processos; - Determinar a adequação dos processos de uma organização para um requisito particular ou uma classe de requisitos; - Determinar a adequação dos processos de outra organização para um determinado contrato ou classe de contratos.