FACULDADE LOURENÇO FILHO PEDRO EMILIANO DE OLIVEIRA REBOUÇAS

Tamanho: px
Começar a partir da página:

Download "FACULDADE LOURENÇO FILHO PEDRO EMILIANO DE OLIVEIRA REBOUÇAS"

Transcrição

1 FACULDADE LOURENÇO FILHO PEDRO EMILIANO DE OLIVEIRA REBOUÇAS MAPEAMENTO DO PROCESSO UNIFICADO EM RELAÇÃO AO CMMI BUSCANDO COMPATIBILIDADE COM O MPS.BR FOCADO NA GERÊNCIA DE REQUISITOS FORTALEZA 2007

2 PEDRO EMILIANO DE OLIVEIRA REBOUÇAS MAPEAMENTO DO PROCESSO UNIFICADO EM RELAÇÃO AO CMMI BUSCANDO COMPATIBILIDADE COM O MPS.BR FOCADO NA GERÊNCIA DE REQUISITOS Trabalho apresentado como exigência parcial para obtenção do grau de Bacharel em Ciência da Computação à comissão julgadora da Faculdade Lourenço Filho sob orientação da Profa. Ms. Valneide Cabral. FORTALEZA 2007

3 MONOGRAFIA APRESENTADA À COORDENAÇÃO DO CURSO DE CIÊNCIA DA COMPUTAÇÃO DA FACULDADE LOURENÇO FILHO, INTITULADA, MAPEAMENTO DO PROCESSO UNIFICADO EM RELAÇÃO AO CMMI BUSCANDO COMPATIBILIDADE COM O MPS.BR FOCADO NA GERÊNCIA DE REQUISITOS, COMO REQUISITO PARA OBTENÇÃO DO GRAU DE BACHAREL EM CIÊNCIA DA COMPUTAÇÃO. POR: PEDRO EMILIANO DE OLIVEIRA REBOUÇAS APROVADA EM: 26/ 03/ BANCA EXAMINADORA CONSTITUÍDA DOS SEGUINTES PROFESSORES: Profa. Ms. Fabiana Gomes Marinho Prof. Ms. José Alzir Bruno Falcão Profa. Ms. VALNEIDE CABRAL ORIENTADORA

4 Resumo Apresento um estudo da problemática do processo de desenvolvimento de software, assim também como os modelos de desenvolvimento, visando a qualidade de produtos de software baseada em normas de qualidade. Exploraram-se características comuns que pudessem servir para associar os três modelos escolhidos: RUP, CMMI e MPS.Br. Dessa forma, a estrutura de cada um dos modelos foi compreendida e o mapeamento foi planejado. Além disso, houve um entendimento mais detalhado das práticas e resultados dos modelos, sendo necessário para mapeá-los de forma mais ampla. Por fim, o mapeamento entre práticas específicas, atividades e resultados esperados foi efetivamente realizado para cada um dos processos dos dois primeiros níveis do MPS.Br. Com este mapeamento, foi possível encontrar as atividades sugeridas pelo CMMI para a implementação de um processo de nível F no modelo brasileiro. Constatou-se uma associação entre os modelos analisados, com ênfase na gerência de requisitos.

5 Abstract I present a study of the problematic one of the process of software development, thus also as the development models, aiming at the quality of products of software based on quality norms. They had been explored characteristic common that could serve to associate the three chosen models: RUP, CMMI and MPS.Br. Of this form, the structure of each one of the models was understood and the mapping was planned. Moreover, it more had a detailed agreement of practical and the results of the models, being necessary to mapear them of ampler form. Finally, the mapping between practical specific, waited activities and results effectively were carried through for each one of the processes of the two first levels of the MPS.Br. With this mapping, were possible to find the activities suggested for the CMMI for the implementation of a process of level F in the Brazilian model. An association between the analyzed models was evidenced, with emphasis in the management of requirements.

6 Sumário Introdução 08 Capítulo 1 - Processos de Software Problemas no desenvolvimento de software Causas de falhas no desenvolvimento Por que utilizar um processo Preocupação com a qualidade de produtos de software 12 Capítulo 2 - Qualidade de produtos de software Qualidade de Software Qualidade do Produto Características de qualidade do produto Norma ISO 9126 (NBR 13596) Norma ISO Capítulo 3 - Modelos de processo de desenvolvimento de software Contribuições dos Modelos precursores Modelos Contemporâneos Formal O processo unificado Características do processo unificado (RUP) Ágil Extreme programming (XP) SCRUM Ágil/ Formal MSF (Microsoft Solutions Framework) 48 Capítulo 4 Modelos para avaliação e melhoria de processos CMMI Representação por estágio Representação contínua MPS BR 57 Capítulo 5 Mapeamento do processo unificado em relação ao CMMI buscando a compatibilidade com o MPS.BR focado na gerência de requisitos 65 Conclusão 73 Bibliografia 74

7 Introdução Para obter a perspectiva de mapeamento apresentada neste trabalho, foi feito um estudo dos modelos de processo de desenvolvimento de software, identificando características comuns que pudessem servir para associar os modelos escolhidos: RUP, CMMI e MPS.Br. Dessa forma, a estrutura de cada um dos modelos foi compreendida e o mapeamento foi planejado. Além disso, houve um entendimento mais detalhado das práticas e resultados dos modelos, sendo necessário para mapeá-los de forma mais ampla. Por fim, o mapeamento entre práticas específicas, atividades e resultados esperados foi efetivamente realizado para cada um dos processos dos dois primeiros níveis do MPS.Br. Com este mapeamento, foi possível encontrar as atividades sugeridas pelo CMMI para a implementação de um processo de nível F no modelo brasileiro. O presente trabalho foi estruturado da seguinte forma: O capítulo 1 introduz a temática, apresentando os problemas no desenvolvimento de software, as causas de falhas no desenvolvimento, as indagações que remetem utilizar os processos e a preocupação com sua qualidade; O capítulo 2 aborda a qualidade de produtos de software baseado nas normas de qualidade e suas características; O capítulo 3 descreve os modelos de processo de desenvolvimento de software desde os precursores até os contemporâneos; O capítulo 4 apresenta os modelos para avaliação e melhoria dos processos; O capítulo 5 explica o mapeamento entre o RUP e CMMI 2 buscando compatibilidade com os resultados esperados proposto pelo modelo MPS.Br, focado na gerência de requisitos.

8 1 Processos de software 1.1 PROBLEMAS NO DESENVOLVIMENTO DE SOFTWARE Um conjunto de problemas é encontrado, no desenvolvimento de softwares, os quais não se limitam ao não funcionamento adequado do mesmo. Em vez disso, a aflição inclui problemas associados com a maneira como desenvolvemos o software, como suportamos um volume crescente de software existente e como podemos enfrentar uma crescente demanda por mais software (PRESSMAN, 2002, p.11). Dentre esses problemas, Pressman (2002) destaca os três nos quais os gerentes de projeto mais se concentram: as estimativas de prazo e de custo freqüentemente são imprecisas; a produtividade das pessoas da área de software não acompanha a demanda; a qualidade de software não é adequada. Os elevados custos do software sejam eles para o desenvolvimento ou manutenção tem sido objetos de constantes discussões entre a área contratante e de desenvolvimento. Os prazos estimados geralmente não são cumpridos e os índices de erros para novos programas causam insatisfação ao cliente gerando frustrações e desconfiança. Além dessas, Pressman (1995) destaca as seguintes dificuldades no desenvolvimento de software: a) não dedicação de tempo para coletar dados sobre o processo de desenvolvimento de software; b) insatisfação do cliente com o sistema

9 concluído ; c) a qualidade de software frequentemente é suspeita devido a pouca importância dada aos testes de software. 1.2 CAUSAS DE FALHAS NO DESENVOLVIMENTO Os problemas associados ao desenvolvimento e manutenção de software, segundo Pressman (1995, p.24), foram causados pelo próprio caráter do software e pelas falhas das pessoas que detinham a responsabilidade pelo desenvolvimento de software. Esta também é uma atividade nova com pouco mais de quarenta anos. O software, por ser de natureza lógica, torna-se um desafio para as pessoas que o desenvolvem, mais os problemas vistos anteriormente são causados por falhas humanas. Gerências médias e altas com pouca preparação e qualificação assumem a responsabilidade pelo gerenciamento e desenvolvimento de projetos de sistemas para computadores. A falta de comunicação entre os atores envolvidos no processo cria uma incompreensão do software a ser desenvolvido e quando isso ocorre os problemas associados às falhas serão inevitáveis. De acordo com Hartman e Ashraf (2002, p.2), os problemas mais comumente relatados na literatura como causas de falhas em projetos de software são: requisitos mal interpretados; cronogramas e orçamentos otimistas; avaliação e gestão de riscos inadequados; padrões inconsistentes e ausência de treinamento em gestão de projetos; gestão dos recursos, principalmente pessoas; falta de clareza no contrato do projeto; ausência de comunicação. Para Prado (1999, p.20), os fatores críticos de sucesso de um projeto de software, ou seja, itens que devem ser observados durante o planejamento e execução do projeto para que o sucesso seja alcançado, são: gerência competente; equipe competente; planejamento e controle adequados; inexistência ou neutralização antecipada dos itens de alto risco; atenção especial às ferramentas gerenciais mais estratégicas. Além disso, Prado (1999, p.28) destaca quatro pontos importantes para o acompanhamento e execução dos projetos de software. São eles: gerência à vista (divulgação do planejamento aos envolvidos); acompanhamento dos trabalhos; controle de modificações; controle da qualidade. Nota-se que os pontos apresentados pelos diversos autores são bastante semelhantes. Os estudos revelam que o grande desafio da engenharia de software tem sido desenvolver um produto com qualidade assegurada, elevada produtividade, dentro do

10 prazo estabelecido e sem necessitar de mais recursos que os alocados. A principal causa dos problemas segundo os especialistas é a falta de um processo de desenvolvimento de software claramente definido e utilizado, que permite a coleta de lições aprendidas e a incorporação de novas tecnologias num processo de melhoria contínua. A qualidade dos produtos de software está diretamente relacionada com a qualidade do seu processo de desenvolvimento. Apesar de extensa literatura fundamentando as causas de problemas no desenvolvimento de software, observa-se semelhanças entre os autores nas causas e conseqüências apresentadas. Todos são unânimes em destacar a falta de um processo de desenvolvimento de software como causa principal. A utilização de um processo se justifica na medida em que viabiliza o desenvolvimento de software com a qualidade desejada, razão pela qual várias empresas têm obtido a melhoria na qualidade de seus produtos de software e melhores resultados em seus negócios. Desse modo torna-se imprescindível a utilização de processos de software no intuito de minimizar os problemas oriundos do desenvolvimento dos projetos de software como também melhorar a qualidade do produto. 1.3 POR QUE UTILIZAR UM PROCESSO O processo de software é uma sequência coerente de práticas que objetiva o desenvolvimento ou evolução de sistemas de software. Pode ser definido também como um conjunto de atividades e resultados associados que geram um produto de software. Estas práticas englobam as atividades de especificação, projeto, implementação e testes e caracterizam-se pela interação de ferramentas, pessoas e métodos. Essas atividades são fundamentais e comuns a todos os processos de software. A especificação de software, consiste em definir a funcionalidade do software e as restrições em sua operação. Na área de projeto e implementação, deve-se produzir software de modo que cumpra sua especificação. Para a validação, são necessários testes para garantir que o software produzido realize o que cliente deseja. E na evolução de software, verifica-se que o mesmo precisa sofrer mutações para atender às necessidades dos clientes (SOMMERVILLE, 2003). Atualmente, existem vários processos de desenvolvimento de software com o objetivo de auxiliar grupos de desenvolvimento a desenvolverem produtos de software

11 com qualidade, capazes de atender as necessidades e exigências dos usuários. Por outro lado, para que seja possível desenvolver softwares com a qualidade desejada é fundamental que o processo utilizado seja bem definido, consistente e gerenciável. A utilização da melhoria de processo para a obtenção da melhoria necessária e viável das empresas de software tem aumentado nos últimos anos no Brasil e no mundo. Os objetivos desta melhoria são composições de fatores como menores custos, menores prazos, maior previsibilidade, maior satisfação dos funcionários, clientes e usuários, e menor número de defeitos no produto final. Esta melhoria tem sido baseada em modelos de processos, como SW-CMM, ISO/IEC (SPICE), CMMI, ISO 9001, ISO/IEC 12207, entre outros. Neste sentido, com o objetivo de se tornarem mais competitivas, várias organizações estão implantando com sucesso a gerência disciplinada dos processos utilizados para planejar, gerenciar, monitorar, controlar e melhorar as atividades desenvolvidas para a aquisição, desenvolvimento, manutenção, operação, evolução e suporte de software. Por meio da melhoria de seus processos, estas organizações têm obtido a necessária melhoria da qualidade de seus produtos e melhores resultados em seus negócios. 1.4 PREOCUPAÇÃO COM A QUALIDADE DE PRODUTOS DE SOFTWARES A qualidade tornou-se, nos últimos anos, um dos principais fatores de competição em todas as áreas de atividade econômica. A busca pela sobrevivência em mercados cada vez mais globalizados tem tornado a qualidade dos produtos uma necessidade evidente. Na área de software a realidade é a mesma. Além de ter como necessidade a melhoria da qualidade do produto final, resultante do processo de desenvolvimento de software, as empresas têm se preocupado em melhorar o próprio processo de desenvolvimento como forma de buscar garantir a qualidade do produto em si. As organizações passam, continuamente, por freqüentes mudanças com objetivos de alcançar mercados e atender as necessidades de seus clientes que, sucessivamente, estão mais informados, exigentes e diferenciados. De acordo com Anjard (1998), para que as organizações aumentem sua capacidade competitiva, algumas formas de melhoria contínua são necessárias, devendo essas organizações competir em todas as direções, mais especialmente com a qualidade de seus produtos e serviços.

12 A globalização da economia e a concorrência cada vez mais acirrada justificam toda uma preocupação por parte das empresas com relação aos seus clientes, uma vez que consideram principalmente os aspectos relacionados à qualidade dos serviços ou produtos oferecidos e a forma de atendimento. A globalização econômica, bem como a competitividade entre as empresas, fez com que a qualidade se tornasse fator essencial para a sobrevivência das organizações e sua manutenção no mercado. Atualmente, as organizações procuram atingir um alto nível de qualidade em produtos e serviços, pois não é mais aceitável entregar produtos com baixa qualidade e reparar os problemas e as deficiências depois que os produtos foram entregues aos clientes. Contudo, a qualidade do software é um conceito complexo, que não pode ser definido de maneira simplificada. Classicamente, a noção de qualidade tem sido a de que o produto desenvolvido deve cumprir com sua especificação (CROSBY, 1979).

13 2 Qualidade de produtos de software 2.1 QUALIDADE DE SOFTWARE O conceito de qualidade é bastante antigo. Para Deming (1982), um dos grandes líderes do gerenciamento da qualidade, a qualidade é definida como um grau previsível de uniformidade e dependência, baixo custo e satisfação no mercado. Ou seja, qualidade é sempre aquilo que o cliente necessita e quer. O conceito de qualidade tem evoluído ao longo do tempo, acompanhando os novos conceitos da área de administração. Este conceito foi incorporado a diversas áreas, assim como a de software. Fisher e Light (1979) definiram qualidade de software como um conjunto de atributos que descrevem o grau de excelência de um sistema computacional. A ISO (Internacional Standard Organization) define como uma totalidade de características que influenciam a habilidade de satisfazer necessidades explícitas ou implícitas para o desenvolvimento de um software. Yourdon (1995) entende qualidade como ter um sistema que funcione, faça exatamente o que o cliente espera, fique pronto no prazo, mereça confiança e possa ser modificado e mantido. Outro estudioso na temática, Pressman (2002), a define como conformidade com os requisitos funcionais e de performance explicitamente especificados, padrões de desenvolvimento explicitamente documentados e características implícitas que são esperadas por qualquer software desenvolvido profissionalmente.

14 Ainda, existem outros autores que defendem que a qualidade de software pode ser vista sobre duas diferentes abordagens, a qualidade dos produtos de software e a qualidade dos processos de desenvolvimento e manutenção dos mesmos. Geralmente a primeira é caracterizada pela realização de testes e a segunda, de auditorias. A ênfase na abordagem da qualidade dos produtos de software se dá, principalmente, em função das constantes mudanças de tecnologias e recursos que os profissionais da área de software vêm enfrentando nos últimos tempos. Estas constantes mudanças acabam não permitindo um pleno domínio sobre as novas tecnologias, em função da rapidez que devem ser estudadas e tornarem-se conhecidas. Como conseqüência, é preciso dar-se mais atenção à prevenção de erros no processo de desenvolvimento. Desta forma, alguns autores acreditam que a qualidade de software é, antes de tudo, a realização de testes com o objetivo de prevenir erros (KAYANI, 2002; MOLINARI, 2000). A qualidade de software não pode ser avaliada de maneira isolada. Softwares são desenvolvidos pelas organizações através de procedimentos. Um método pobre ou a ausência de uma metodologia pode ser a causa da baixa qualidade. Sendo assim, a avaliação da qualidade está diretamente relacionada com a qualidade de processos e metodologias utilizadas. Assim, a qualidade foi deixando de ser um diferencial competitivo para se tornar necessidade básica entre as organizações a fim de buscar o estabelecimento e crescimento no mercado. 2.2 QUALIDADE DO PRODUTO Antes de tudo, precisa-se entender que ao falar de software e de sua engenharia está se tratando ao mesmo tempo de produtos e de processos. De nada adianta centrar a atenção só no produto ou só no processo. É necessário que as duas visões caminhem juntas. Portanto, para lidar com qualidade é necessário termos claro que o processo de produção deve ter qualidade e que o produto deve ter qualidade. Durante muito tempo a engenharia de software focalizou sua atenção na qualidade do produto. Nessa visão orientada a produto destacam-se três aspectos que, acredita-se, dominaram a pesquisa e a prática da construção de software. Uma ênfase na qualidade das representações, isto é nas linguagens artificiais.

15 A crença de que a qualidade do produto é função principalmente de teste do produto final. Que o processo de produção era centrado em fases caracterizadas por produtos bem definidos. A qualidade das representações sejam elas executáveis ou não, é um importante aspecto da engenharia de software. Linguagens de programação mais robustas, de maior confiabilidade e de maior nível de abstração é, ainda hoje, um tema de discussão. Muitas vezes essas discussões saem do nível técnico e passam a ser discussões mais voltadas para gostos pessoais. Vale lembrar que na década de 80 a grande discussão era sobre ADA e que no final dos anos noventa passou a ser sobre JAVA, apenas para citar duas linguagens que geraram e ainda hoje geram muito debate. Sob o ponto de vista de representações mais abstratas, e a princípio, não executáveis, o ponto central são linguagens de especificação. Por um lado tem-se a necessidade de linguagens formais e abstratas e por outro a necessidade de linguagens de fácil comunicação como também abstratas. O papel do teste, fundamental na produção de qualquer produto, foi e, ainda hoje é visto, principalmente, como teste de programas, isto é teste de descrições em linguagens de programação. Hoje se dispõe de técnicas de teste, de ferramentas de teste e de facilidades embutidas nas linguagens de programação que possibilitam ao engenheiro de software o uso de um valioso arsenal para combater a presença de defeitos no produto final. No entanto, sabe-se que esse processo é extremamente dispendioso e muitas vezes envolve um grande número de recursos humanos para garantir um nível mínimo de qualidade. A visão inicial do processo de produção, ou ciclo de vida do software, era centrada em produtos bem definidos e em regras de verificação entre produtos. Esses produtos, com características bem definidas eram vistos como passos ou fases num processo, que apesar da possível retroalimentação, fundamentava-se na visão de seqüencialidade. Mesmo em propostas não seqüenciais, como a prototipação, ainda assim a atenção principal é dirigida às representações dos produtos. Hoje se tem uma visão muito mais abrangente. Primeiro, sabe-se que o processo de produção é fundamental para obtenção de produtos de qualidade. Segundo, tem-se uma visão mais equilibrada dos aspectos essenciais e acidentais da engenharia de software. Terceiro, a sociedade passa a entender melhor os custos relacionados com a evolução do software. Desse modo, entende-se que a visão da construção de software

16 como um processo em que normas, procedimentos e gerência devem estar bem definidos para garantir a qualidade dos produtos, é diferente da visão do processo de produção centrando em fases/produtos. Nesta visão, o papel da gerência passa a ser visto como um aspecto técnico e não como um aspecto exterior ao conhecimento da engenharia de software. Procura-se focalizar a atenção na aquisição de dados sobre o processo e a transformação desses dados em conhecimento sobre o processo de produção (HUMPHREY, 1995). A recente crise do ano 2000 e as constantes notícias de sistemas de software com problemas ajudaram a sociedade a entender software como parte de suas vidas (LEVENSON, 1993; BREITMAN, 1999). Esse amadurecimento da sociedade passou a gerar uma maior demanda por qualidade. Também passou a ficar mais claro que a evolução do software, tendo em vista o caso do ano 2000, tem um custo. Se por um lado a sociedade passa cada vez mais a depender de software, exigir mais qualidade dos produtos de software e pressionar por mudanças, por outro fica mais claro que existe um custo associado e não completamente entendido. Pelo fato de a sociedade moderna depender cada vez mais do software para sua própria evolução, maior será o desafio dos engenheiros de software para manter a qualidade desejada dentro dos recursos disponíveis. 2.3 CARACTERÍSTICAS DE QUALIDADE DO PRODUTO A qualidade de produto é definida por um conjunto de características que devem ser alcançadas em um determinado grau para que o produto atenda às necessidades de seus usuários. É através deste conjunto de características que a qualidade de um produto pode ser descrita e avaliada (ROCHA et al, 2001). Ou seja, o produto deve apresentar conformidade a requerimentos. Produzir software de qualidade é uma meta básica da Engenharia de Software, que disponibiliza métodos, técnicas e ferramentas para este fim. Há muita literatura escrita sobre qualidade e seus vários adjetivos, no entanto, o fundamental é que o software seja confiável, isto é seja eficaz e siga os padrões exigidos pelo contexto onde irá atuar. Há dois tipos de qualidade e diversos autores fazem uma distinção entre qualidade básica e qualidade extra. Em qualidade básica são listadas: funcionalidade, confiabilidade, facilidade de uso, economia e segurança de uso. Funcionalidade são funções para satisfazer necessidades explícitas e implícitas como também empregada

17 para descrever o que faz o software e demais características. Confiabilidade, definida de acordo com a ISO 8402, é a capacidade de um item desempenhar uma função requerida. Já a ISO 9126 define como um conjunto de atributos que têm impacto na capacidade do software de manter o seu nível de desempenho dentro de condições estabelecidas por um dado período de tempo. A usabilidade é entendida como a facilidade de uso. Entre as características da qualidade extra, estão: flexibilidade, facilidade de reparo ou manutenibilidade definida como facilidade para fazer alterações, adaptabilidade, facilidade de entendimento, boa documentação e facilidade de adicionar melhorias. Este tipo de classificação reforça a idéia do que está sendo elaborado por estudiosos, mas é importante ressaltar que dar prioridade a essas qualidades depende de cada caso e do custo de cada uma dessas qualidades. No entanto, cada vez mais a sociedade pressiona o setor de software para que a característica qualidade seja preponderante. Normas internacionais como a ISO e iniciativas como a da SEI (Software Engineering Institute) são exemplos disso NORMA ISO 9126 A norma internacional ISO/IEC 9126, publicada em 1991 e que na versão brasileira de agosto de 1996 recebeu o número NBR 13596, define qualidade de software como A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas. Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. São, portanto fatores relativos à qualidade do processo de desenvolvimento do produto e são percebidos somente pelas pessoas que trabalharam no seu desenvolvimento. As necessidades implícitas são necessidades subjetivas dos usuários (inclusive operadores, destinatários dos resultados do software e os mantenedores do produto), são também chamadas de fatores externos e podem ser percebidas tanto pelos desenvolvedores quanto pelos usuários. As necessidades implícitas são também chamadas de qualidade em uso e devem permitir os usuários atingir metas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado. A ISO/IEC 9126 (NBR 13596) fornece um modelo de propósito geral o qual define seis amplas categorias de características de qualidade de software que são, por sua vez, subdivididas em subcaracterísticas:

18 Quadro 1: Características e subcaracterísticas de qualidade de software (KOSCIANSKI et al, 2006). ubca O modelo proposto pela ISO/IEC 9126 (NBR 13596) tem por objetivo servir de referência básica na avaliação de produto de software. Além de ter força de norma internacional, ela cobre os aspectos mais importantes para qualquer produto de software NORMA ISO Esta Norma foi criada para atender aos pacotes de software (processadores de texto, planilhas eletrônicas, bancos de dados, softwares gráficos, programas para funções técnicas ou científicas e programas utilitários), também conhecidos internacionalmente como COTS Commercial off the Self, estabelecendo requisitos de

19 qualidade e instruções a respeito de como testar um pacote de software em relação aos requisitos estabelecidos. Estes requisitos compreendem: descrição do produto, documentação do usuário e programas e dados. A descrição do produto inclui as principais propriedades do pacote. A documentação do usuário nada mais é que um documento que será avaliado em relação à sua completitude, correção, consistência, inteligibilidade, apresentação e organização. Programas e dados, na verdade, são os requisitos de programas e dados que devem estar descritos, caso existam, para funcionamento do produto. Um pacote de software está em conformidade com esta Norma se atende a todos os requisitos de qualidade nela definidos. As instruções para teste, definidas na Norma, incluem tanto o teste das propriedades necessárias a todos os produtos de mesmo uso quanto o teste das propriedades especificadas na descrição do produto. A norma é subdividida em dois grupos: os requisitos de qualidade e as instruções para testes. Quanto aos requisitos de qualidade, eles são subdivididos em: Requisitos de descrição do produto: a descrição do produto apresenta as principais propriedades do pacote, e deverá estar à disposição independente do compromisso de compra, por parte do potencial usuário. Segundo a norma "a Descrição de Produto é um documento expondo as propriedades de um pacote de software, com o objetivo de auxiliar os potenciais compradores na avaliação da adequação do produto para sua aquisição" (IEES,1997). Essa descrição deverá conter: Identificação do produtor/fornecedor; Identificação do produto (nome, versão, etc.); Indicação da aplicação geral; Requisitos mínimos de hardware e software; Itens a serem entregues na compra do pacote (discos, manuais, caixa, etc.); Principais funcionalidades disponíveis no pacote; Maneiras para evitar-se o acesso não autorizado ao software (senhas, etc.); Valores limítrofes (número máximo de registros, tamanho das chaves, tempos de resposta, etc.); Procedimentos de segurança em caso de falhas;

20 Detalhes sobre a interface com o usuário; Conhecimentos específicos, requeridos para a aplicação do produto; Dispositivos e métodos para adaptação do produto às necessidades específicas dos usuários; Serviço de manutenção e suporte técnico; Interfaces disponíveis, para outros produtos e possibilidade de portabilidade para outros ambientes operacionais e Proteções técnicas contra infração a direitos autorais; Requisitos da documentação do usuário: trata-se do conjunto de documentos a serem fornecidos para a utilização do software. Esses documentos deverão ter uma apresentação e uma organização que facilitem o seu manuseio, e os requisitos dessa documentação são: completeza, correção, consistência e inteligibilidade; Requisitos dos programas e dados: os programas e dados deverão estar em conformidade com todos os requisitos declarados na documentação, sendo levados em conta os mesmos requisitos da norma ISO/IEC 9126, com ênfase nos requisitos: funcionalidade, confiabilidade e usabilidade. Quanto às instruções para testes, são formalizados os métodos de teste, que são, essencialmente, planejados segundo os requisitos de qualidade, identificados anteriormente: Fase de pré-requisitos de teste: identifica a presença dos itens e dos componentes do software, prevê o acesso ao material de treinamento, caso esse material seja mencionado na descrição do produto; Fase de atividade de teste: todos os requisitos especificados nas documentações e nos programas deverão ser testados; Fase de registros e relatórios de teste: deverão ser coletados os resultados dos testes e esses resultados precisam ser tabulados e analisados; Fase de teste de acompanhamento: para o caso de teste em programas já testados anteriormente. Nesse caso, as partes que não estavam em conformidade deverão ser testadas, bem como todas as partes que podem sofrer influências dessas alterações.

21 3 Modelos de processo de desenvolvimento de software Um processo de desenvolvimento de software é um conjunto de passos parcialmente ordenados concebidos de forma a atingir um objetivo, que no caso da Engenharia de Software, é o de construir ou alterar um produto de software (KRUCHTEN, 1998). De acordo com Ambler (2001), o processo de desenvolvimento de software define quem irá fazer o que e como será atingido o objetivo. Processo de software é um jogo de fases do projeto incluindo estágios, métodos, técnicas e ferramentas empregadas para desenvolver e manter o software e seus artefatos associados (plantas, modelos, códigos, casos de teste, e manuais). Segundo Silva e Videira (2001), um processo de desenvolvimento de software define: workflows, atividades, artefatos, e o papel dos participantes. Possui quatro objetivos fundamentais, entre eles: orientar as seqüências de atividades envolvidas, especificar modelos do sistema que devem ser desenvolvidos, dirigir as tarefas dos participantes e da equipe como um todo e monitorar os modelos e atividades do projeto. Inicialmente, serão enfatizadas três abordagens básicas para o processo de desenvolvimento de software: processos em cascata, processos iterativos e incrementais e o modelo espiral. Entretanto, outras abordagens serão apresentadas pelo fato de serem constantemente utilizadas, como o RAD e a prototipagem rápida.

22 3.1 CONTRIBUIÇÕES DOS MODELOS PRECURSORES Pressman (1995) define os Processos em Cascata como uma abordagem seqüencial para a construção de software, onde as atividades são agrupadas em tarefas executadas seqüencialmente, de forma que se inicia no nível do sistema e avança ao longo da engenharia, análise, projeto, codificação, teste e manutenção: Engenharia: coleta dos requisitos; análise de alto nível; visão essencial do sistema (hardware, banco de dados, softwares de apoio); Análise de Requisitos: processo de coleta detalhada dos requisitos; modelagem do sistema; desempenho; Projeto: traduzir os requisitos em representações (especificações); Codificação: passagem das especificações para uma linguagem de programação; Testes: testar programas e sistemas integrados para verificação de erros de códigos; Manutenção: correção de falhas e mudanças de requisitos; Alguns autores ressaltam que um dos principais problemas encontrados nesse tipo de processo é a dificuldade de seguir o fluxo seqüencial proposto, pois os resultados são demorados e não promovem reusabilidade (SILVA; VIDEIRA, 2001). Os processos Iterativos e Incrementais proporcionam a construção de software mais robusto e com melhor qualidade, devido a melhor interação e comunicação entre os desenvolvedores do sistema (SILVA; VIDEIRA, 2001). O processo iterativo corresponde à idéia de melhorar pouco a pouco o sistema. Já o processo incremental a de aumentar pouco a pouco o contexto do sistema. O processo iterativo e incremental permite verificar e avaliar mais cedo os riscos e os pontos significativos do projeto identificado, além disso, permite identificar os verdadeiros requisitos do sistema mantendo análise, o projeto e a implementação consistentes (SILVA; VIDEIRA, 2001). As fases do processo iterativo podem ser divididas em tarefas mais específicas: Planejamento: identificam-se as necessidades gerais, identificam alternativas e define o plano do trabalho. Análise: procura identificar detalhadamente as funcionalidades do sistema (Levantamento de Requisitos) e a respectiva descrição (Especificação).

23 Projeto: é realizada a definição da arquitetura do software (módulos, tabelas, interface, máquinas, etc). Desenvolvimento: tarefa na qual é realizada a programação dos componentes. Testes: são realizados os testes para verificar se os objetivos foram atingidos. Instalação: disponibiliza o software para o cliente. Manutenção: são efetuadas alterações no produto final de acordo com as suas necessidades. Numa primeira iteração deve-se identificar a visão global e determinar a viabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de projeto e implementação. Numa segunda iteração, deve-se concluir a análise, fazer o projeto e mais um pouco de implementação. Numa terceira iteração, deve-se concluir o projeto, fazer a implementação, testar e integrar um pouco. A cada iteração, será produzido um conjunto de produtos finais que serão completados ao longo do tempo. Figura 1 - Processo iterativo e incremental (SILVA; VIDEIRA, 2001). Para a engenharia de software o modelo espiral é uma pequena variante do modelo iterativo e incremental. Foi proposto por Barry Boehm em 1988 como resposta às críticas que os processos existentes até então, não favoreciam a utilização de prototipagem e reutilização de software, além disso, um novo elemento foi acrescentado a análise de riscos (PRESSMAN, 1995).

24 Figura 2 Modelo Espiral (PRESSMAN, 1995). Cada iteração ao redor da espiral, produz versões mais completas do software. Durante o primeiro giro ao redor da espiral, os objetivos, as alternativas e as restrições são definidas e os riscos são identificados e analisados. Se a análise dos riscos verificar que há problemas ou incertezas nos requisitos, a prototipação pode ser usada no quadrante da engenharia para ajudar o desenvolvedor e o cliente. O cliente avalia o trabalho de engenharia (o quadrante de avaliação do cliente) e apresenta sugestões para modificações. Baseado nestas informações ocorre a fase de planejamento e em seguida a análise dos riscos. Em cada arco da espiral, a conclusão de análise de riscos resulta em uma decisão de continuar ou não continuar com o desenvolvimento. Se os riscos forem elevados o projeto pode ser encerrado (PRESSMAN, 1995). Outro modelo é a técnica de prototipagem rápida. De acordo com Bevan e Curson (1998), é uma coleção de técnicas formais e informais para o desenvolvimento, demonstração e avaliação do design de interfaces de usuários, que dá suporte a iterações rápidas. Entretanto essa técnica também pode ser utilizada como parte integrante do processo iterativo de desenvolvimento de software. Um protótipo é uma versão preliminar do produto final, nesse caso o software. Ele se torna acessível já nas fases iniciais do processo de desenvolvimento do produto. Normalmente a engenharia de software faz uso de protótipos no processo de validação dos requisitos, principalmente quando esses são vagos, ou indefinidos. (SOMMERVILLE; KONTONYA, 1998). Desta forma, é importante que a sua construção se dê de maneira rápida, a fim de não atrasar as demais atividades de desenvolvimento. Eles também podem ser utilizados como forma de comunicação entre

25 os membros da equipe de desenvolvimento e os stakeholders 1. A solução proposta pela prototipagem rápida é justamente a de que um membro da equipe de desenvolvimento, de uma dada iteração, tenha a chance de avaliar a viabilidade de alterações, ou novas solicitações no projeto o mais cedo possível. O RAD (Rapid Application Development) apresenta uma abordagem de criação rápida de aplicativos através da reutilização de componentes de software. As atividades do modelo RAD são: modelagem do negócio, modelagem dos dados, modelagem do processo, geração da aplicação e teste e modificação. Esta abordagem é usada em projetos cujas restrições de tempo impostas demandam o escopo de escala, quando a aplicação pode ser modularizada de forma que cada grande função possa ser completada em menos de 3 meses e cada grande função pode ser alocada para uma equipe distinta, e depois são integradas para formar o todo. Para projetos escaláveis, o RAD requer recursos humanos suficientes para criar um número adequado de equipes RAD. Supõe-se um comprometimento entre desenvolvedores e clientes para que as atividades possam ser realizadas rapidamente e o sistema seja concluído em tempo abreviado. No caso do comprometimento ser abandonado por qualquer das partes, o projeto falhará e os riscos técnicos serão enormes. Após delimitar essas abordagens, detalharemos também os modelos contemporâneos que estão em evidência na atualidade. 3.2 MODELOS CONTEMPORÂNEOS Ao longo dos anos, muitos padrões de processos de software foram definidos com o objetivo de ajudar as organizações a construírem software de uma forma controlada. Inicialmente, tais padrões tinham o objetivo de ser genéricos no sentido de definir uma grande quantidade de atividades e papéis para produzir muitos artefatos e documentos detalhados. Exemplos de padrões desse tipo são os processos Rational Unified Process (RUP) e OPEN que vem sendo utilizado com muito sucesso no meio empresarial. Estes processos são mais adequados a empresas com equipes grandes e projetos complexos onde existe a necessidade de uma extensa e detalhada documentação para redução de riscos. 1 Stakeholder ou, em Português, parte interessada ou interveniente, refere-se a todos os envolvidos em um processo, por exemplo, clientes, colaboradores, investidores, fornecedores, comunidade, etc.

26 Recentemente, muitos pesquisadores e renomados consultores empresariais especialistas na área de desenvolvimento de software, passaram a questionar a eficiência dos processos comentados acima passando a chamá-los de processos pesados. Eles afirmam que os processos pesados, ou formais burocratizam o desenvolvimento de software devido ao excessivo número de atividades e artefatos o que, na opinião deles, acaba desviando o processo daquilo que deveria ser prioritária a entrega constante de software que roda para o cliente. Em 2001, Kent Beck e dezesseis outros notáveis desenvolvedores, produtores e consultores de software (Beck, 2001) assinaram o Manifesto Ágil de software. Os conceitos chave do manifesto ágil são: Indivíduos e interações ao invés de processos e ferramentas. Software executável ao invés de documentação. Colaboração do cliente ao invés de negociação de contratos. Respostas rápidas a mudanças ao invés de seguirem planos. Isso não quer dizer que esse manifesto não considere os itens à direita importantes, mas sim, que os itens são considerados de maior valor. Portanto, os processos ágeis, como Extreme Programming e SCRUM e outros, focam-se em entrega constante de funcionalidade e interação constante entre os membros da equipe e clientes. Esses processos vêm se mostrando eficientes em projetos onde os requisitos são constantemente modificados, os ciclos de desenvolvimento são curtos e as equipes que implementam o projeto são pequenas. Ambos os grupos de processos (ágeis e formais) possuem vantagens e desvantagens. Cada grupo pode ser mais adequado para determinados tipos de projeto, dependendo de fatores como: natureza e complexidade da aplicação a ser construída; tamanho e distribuição da equipe; e restrição de prazo e custo impostos pelo cliente. Nas seções seguintes, será apresentado um panorama de modelo formal (o RUP), de alguns modelos ágeis de processo (Extreme Programming e SCRUM) e do MSF (Microsoft Solutions Framework).

27 3.2.1 FORMAL O PROCESSO UNIFICADO O processo unificado 2 de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software. Ele é baseado em componentes, o que significa o sistema ser construído a partir de componentes de software interconectados via interfaces muito bem definidas. O processo unificado utiliza a Linguagem de Modelagem Unificada (Unified Modeling Language UML) no preparo de todos os artefatos do sistema (SCOTT, 2003). Os aspectos que distinguem o processo unificado são capturados em três conceitos chave: direcionado a casos de uso; centrado na arquitetura; iterativo e incremental. Esses três aspectos serão discutidos nas próximas seções. Um sistema de software é feito para servir seus usuários. Portanto, para construir um sistema de sucesso devemos saber quem são seus usuários potenciais e o que eles querem e precisam. O termo usuário representa alguém ou alguma coisa (como um outro sistema) que interage com o sistema que está sendo desenvolvido. Um caso de uso é um pedaço de funcionalidade do sistema que dá ao usuário um resultado de valor. Casos de uso capturam requisitos funcionais e todos juntos resultam no modelo de casos de uso, o qual descreve a funcionalidade completa do sistema (CHUNG; NIXON, 2000). Este modelo substitui a especificação funcional tradicional, cujo papel é responder à seguinte questão: o que o sistema faz? A estratégia de casos de uso pode ser caracterizada pela adição de três palavras no final dessa pergunta: para cada usuário? Estas palavras têm uma implicação muito importante. Forçam-nos a pensar em termos dos valores dos usuários, não apenas em funções que poderiam ser interessantes. Os casos de uso direcionam o processo de desenvolvimento, já que, baseados no modelo de casos de uso os desenvolvedores criam uma série de modelos de projeto e implementação que os realizam efetivamente. Os responsáveis pelos testes realizam seu trabalho com o propósito de garantir que os componentes do modelo de implementação cumpram corretamente os objetivos estabelecidos nos casos de uso. Desta forma, os casos de uso não somente iniciam o processo de desenvolvimento, mas também o 2 O Processo Unificado é algumas vezes chamado de processo unificado rational (RUP- Rational Unified Process) por causa da Rational Corporation, atualmente da IBM.

28 mantém coeso. Direcionado a casos de uso significa que o processo de desenvolvimento executa uma seqüência de tarefas derivadas dos casos de uso. Eles são especificados, projetados e servem de base para a construção dos casos de teste. Embora seja verdade que os casos de uso dirigem o processo, eles não são selecionados isoladamente. São desenvolvidos juntamente com a arquitetura do sistema. Ou seja, os casos de uso direcionam a arquitetura do sistema, que por sua vez influencia a seleção dos casos de uso. Portanto, ambos amadurecem no decorrer do ciclo de vida do sistema. Centrado na Arquitetura O papel da arquitetura no software é de natureza similar ao papel da arquitetura na construção civil. As construções são observadas sob vários pontos de vista: estrutura, serviços, condução de calor, encanamento, eletricidade, etc. Da mesma forma, a arquitetura em um sistema de software é descrita como sendo as diferentes visões desse sistema (ERIKSSON, et al, 1998; JACOBSON et al, 1999). O conceito de arquitetura de software incorpora os aspectos estáticos e dinâmicos mais importantes do sistema. A arquitetura é influenciada por muitos fatores, tais como a plataforma de software sobre a qual o sistema vai rodar (sistema operacional, sistema gerenciador de banco de dados, protocolos para comunicação em rede, etc.), blocos de construção reusáveis disponíveis (por exemplo, um framework para construção de interface gráfica com o usuário), considerações de distribuição, sistemas legado e requisitos não funcionais (performance, confiabilidade, etc.). Ela representa uma visão do projeto como um todo, na qual as características mais importantes são colocadas em destaque, deixando os detalhes de lado. Como os casos de uso estão relacionados à arquitetura? Todo produto tem função e forma e nenhum desses elementos sozinho é suficiente. Essas duas forças devem ser balanceadas para obtermos um produto de sucesso. Neste caso, a função corresponde aos casos de uso e a forma à arquitetura. Por um lado, os casos de uso devem, quando construídos, encaixar-se na arquitetura. Por outro, a arquitetura deve fornecer espaço para a construção de todos os casos de uso necessários, agora e no futuro. Na realidade, ambos devem ser desenvolvidos em paralelo. Para encontrar essa forma, os arquitetos devem trabalhar a partir de uma compreensão geral das funções chave do sistema, isto é, dos casos de uso chave. Estes devem ficar em torno de 5 a 10% de todos os casos de uso, mas são os mais significativos, aqueles que constituem o núcleo das funções do sistema. Em termos

29 simplificados, os arquitetos criam um esboço da arquitetura iniciando com a parte que não é específica dos casos de uso (por exemplo, a plataforma). Embora seja uma parte independente dos casos de uso, o arquiteto deve ter uma compreensão geral destes antes da criação do esboço. Depois, o arquiteto trabalha com um subconjunto dos casos de uso identificados, aqueles que representam as funções chave do sistema em desenvolvimento. Cada caso de uso selecionado é especificado em detalhes e construído em termos de subsistemas, classes e componentes. À medida que os casos de uso são especificados e atingem maturidade, mais detalhes da arquitetura são descobertos. Isto, por sua vez, leva ao surgimento de mais casos de uso. Este processo continua até que a arquitetura seja considerada estável. Iterativo e Incremental O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser estendida por vários meses, possivelmente um ano ou mais. É mais prático dividir o trabalho em pedaços menores ou miniprojetos. Cada miniprojeto é uma iteração que resulta em um incremento. Iterações são passos em um fluxo de trabalho e incrementos são crescimentos do produto. Os desenvolvedores selecionam o que deve ser feito em cada iteração baseados em dois fatores. Primeiro, a iteração deve trabalhar com um grupo de casos de uso que juntos estendam a usabilidade do produto em desenvolvimento. Segundo, a iteração deve tratar os riscos mais importantes. Um incremento não é necessariamente a adição do código executável correspondente aos casos de uso que pertencem à iteração em andamento. Especialmente nas primeiras fases do ciclo de desenvolvimento, os desenvolvedores podem substituir um projeto superficial por um mais detalhado ou sofisticado. Em fases avançadas os incrementos são tipicamente aditivos. Em cada iteração, os desenvolvedores identificam e especificam os casos de uso relevantes, criam um projeto utilizando a arquitetura escolhida como guia, implementam o projeto em componentes e verificam se esses componentes satisfazem os casos de uso. Se uma iteração atinge seus objetivos, e isso normalmente ocorre, o desenvolvimento prossegue com a próxima iteração, caso contrário, os desenvolvedores devem rever suas decisões e tentar uma nova abordagem. Há vários benefícios em se adotar um processo iterativo controlado, entre os quais podemos destacar:

30 Redução dos riscos envolvendo custos a um único incremento. Se os desenvolvedores precisarem repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração, não o valor de um produto inteiro. Redução do risco de lançar o projeto no mercado fora da data planejada. Identificando os riscos numa fase inicial o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final de projeto. Aceleração do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores trabalham de maneira mais eficiente quando buscam resultados de escopo pequeno e claro. Reconhecimento de uma realidade freqüentemente ignorada: as necessidades dos usuários e os requisitos correspondentes não podem ser totalmente definidos no início do processo. Eles são tipicamente refinados em sucessivas iterações. Este modelo de operação facilita a adaptação a mudanças de requisitos. Os três conceitos apresentados (dirigido a casos de uso, centrado em arquitetura, iterativo e incremental) são igualmente importantes. Remover um deles poderia reduzir drasticamente o valor do processo unificado, e agora que eles foram introduzidos, podese observar o processo como um todo, seu ciclo de vida, produtos, tarefas, fases e iterações. O ciclo de vida do Processo Unificado O processo unificado consiste da repetição de uma série de ciclos durante a vida de um sistema, como mostrado na figura abaixo. Cada ciclo é concluído com uma versão do produto pronta para distribuição. Essa versão é um conjunto relativamente completo e consistente de artefatos, possivelmente incluindo manuais e um módulo executável do sistema, que podem ser distribuídos para usuários internos ou externos. Figura 3: A vida de um processo em ciclos Cada ciclo consiste de quatro fases: início, elaboração, construção e transição. Cada fase é também subdividida em iterações, como discutido anteriormente.

31 Figura 4: Um ciclo com suas fases e iterações O Produto O produto final inclui artefatos de interesse do usuário, tais como manuais e código fonte incorporado em componentes que podem ser compilados e executados, e artefatos que interessam a outras pessoas, como os requisitos, os casos de uso, as especificações não funcionais e os casos de teste. Inclui também modelos da arquitetura. Na realidade, inclui todos os elementos já mencionados, os quais permitem especificar, projetar, implementar, testar e utilizar o sistema. Mesmo que componentes executáveis sejam os produtos mais importantes do ponto de vista dos usuários, sozinhos eles não são suficientes. Isto acontece porque o ambiente muda. Sistemas operacionais, sistemas de bancos de dados e máquinas evoluem. Os próprios requisitos podem mudar à medida que compreendermos melhor a missão do sistema. Na realidade, esta á uma das constantes no desenvolvimento de software: requisitos irão mudar. Para executar um novo ciclo eficientemente, os desenvolvedores precisam de todas as representações do produto: um modelo de casos de uso, contendo todos dos casos de uso e seus relacionamentos com os usuários; um modelo de análise, que tem dois propósitos: refinar os casos de uso em mais detalhes e fazer uma alocação inicial do comportamento do sistema a um conjunto de objetos; um modelo de projeto que define a estrutura estática do sistema em termos de subsistemas, classes e interfaces, e a realização dos casos de uso como sendo colaborações entre subsistemas, classes e interfaces; um modelo de implementação, o qual inclui componentes representando código fonte e o mapeamento entre classes e componentes; um modelo de distribuição que define os nós físicos de computadores e o mapeamento entre os componentes e esses nós; um modelo de teste, o qual descreve os casos de teste que serão usados para verificar os casos de uso;

32 e, é claro, uma representação da arquitetura. O sistema pode ter também um modelo de domínio ou um modelo de negócios que descreva o contexto no qual ele está inserido. Figura 5: Modelos do Processo Unificado Todos esses modelos estão relacionados e juntos representam o sistema como um todo. Elementos em um modelo têm uma ligação com elementos de outro modelo. Por exemplo, um caso de uso pode estar relacionado à sua realização no modelo de projeto e a um caso de teste no modelo de teste. A rastreabilidade facilita a compreensão e a modificação CARACTERÍSTICAS DO PROCESSO UNIFICADO (RUP) O RUP é um processo para engenharia de software formada por ciclos, fases, iterações e marcos (milestones) que integram através de uma linguagem (UML) e processos comuns os usuários finais, programadores, analistas e projetistas de maneira disciplinada, possibilitando o desenvolvimento de software de alta qualidade com cronograma e orçamento pré-definidos. De acordo com Silva e Videira (2001), o RUP suporta boas práticas de desenvolvimento de software, sendo importante citar suas principais características: É uma metodologia de desenvolvimento de software iterativa e incremental. É dirigido por casos de uso (use cases). Defende a modelagem visual. Tenta manter o controle de qualidade permanente.

33 Propõe o desenvolvimento de software baseado em arquiteturas de software e em componentes. Utiliza a UML como linguagem de modelagem. Algumas notações são utilizadas para representação do processo, são elas: Workflow (quando): um workflow define um conjunto de atividades que produz um resultado. Cada workflow requer, usualmente, a interação de diversos participantes (workers). Atividade (como): unidade de trabalho que pode ser atribuído a um worker (trabalhador). Ex: planejamento de uma iteração ou a identificação de casos de uso para atores. Artefatos (o quê): qualquer informação produzida, modificada ou utilizada por um ou mais workers durante uma atividade. Ex: modelo casos de uso, documentos, planos, códigos fontes e executáveis. Cada artefato pode ser elaborado com o apoio de ferramentas distintas. Ex: glossário, protótipo da interface, documentação dos requisitos, (especificação suplementar de requisitos não funcionais). Worker: (quem), define o comportamento e as responsabilidades de um ou mais indivíduos dentro da equipe de trabalho; é o proprietário de um conjunto de artefatos e desenvolvedor de um conjunto de tarefas. Ex: analista de sistemas, programador, etc. É importante ressaltar que as três principais características do RUP conduzido por casos de uso, centrado em uma arquitetura e iterativo e incremental estão eminentemente relacionadas (SILVA; VIDEIRA, 2001). Analisando o aspecto geral do RUP, pode-se considerar que o processo possui duas estruturas, ou seja, duas dimensões: a horizontal representa o tempo e mostra aspectos dos processos no decorrer deste tempo. A vertical representa o centro dos processos disciplinares, organizando as atividades de acordo com sua natureza. Silva e Videira (2001) dizem que a primeira dimensão (horizontal) representa os aspectos dinâmicos do processo, expressando os termos como ciclos, fases, iterações, pontos de controle ou marcos (milestones). No RUP, um produto de software é projetado e construído em uma sucessão de iterações incrementais, ou seja, a produção de software é desenhada e construída sobre

34 uma sucessão lógica de atividades de desenvolvimento. Isso permite testar e definir os objetivos do projeto, minimizar os riscos, e permitir um ciclo de vida mais curto. A segunda dimensão (vertical) representa os aspectos estáticos do processo, descrevendo os itens dos processos existentes: atividades, artefatos, workers e workflows (KRUCHTEN, 2001). Figura 6: As dimensões do RUP (RATIONAL, 1998) Quando se considera o aspecto dinâmico do RUP o projeto é encarado como uma seqüência de fases, cada qual com várias iterações (RATIONAL, 1998). As fases são as seguintes: concepção; elaboração; construção e transição. Cada fase é concluída com um marco (milestone) bem definido, no qual os resultados são comparados com os objetivos principais, onde deverão ser tomadas algumas decisões sobre a continuidade do projeto. Podemos visualizar esses marcos nas linhas verticais tracejadas da Figura acima. Na figura abaixo podemos ter uma visão mais detalhada das fases, iterações e marcos (milestones): Figura 7: Fases, iterações e milestones (SILVA; VIDEIRA, 2001).

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que

Leia mais

Tópicos. Engenharia de Software: Uma Visão Geral

Tópicos. Engenharia de Software: Uma Visão Geral Tópicos 2 3 Engenharia de Software: Uma Visão Geral SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 A importância do Software Software Aplicações

Leia mais

Professor: Curso: Disciplina:

Professor: Curso: Disciplina: Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos

Leia mais

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP RUP Rational Unified Process ( Unificado de Desenvolvimento da Rational) Conjunto de passos que tem como objetivo atingir uma meta de software na ES, processo que visa a produzir o software - de modo eficiente

Leia mais

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Metodologia de Desenvolvimento de Sistemas Aula 1 Ementa Fases do Ciclo de Vida do Desenvolvimento de Software, apresentando como os métodos, ferramentas e procedimentos da engenharia de software, podem

Leia mais

1 Introdução 1.1. Motivação

1 Introdução 1.1. Motivação 9 1 Introdução 1.1. Motivação Ao longo das últimas décadas, observou-se um aumento enorme na complexidade dos sistemas de software desenvolvidos, no número de profissionais que trabalham nesta área, na

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT Disciplina: Modelagem a Programação Orientada a Objetos

Leia mais

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr Metodologia de Desenvolvimento de Software Prof. M.Sc. Sílvio Bacalá Jr Objetivos Discutir aspectos de Engenharia de Software Aplicar um método de desenvolvimento para especificação e projeto de software

Leia mais

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

Leia mais

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Qualidade na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

Leia mais

IC-UNICAMP IC-UNICAMP

IC-UNICAMP IC-UNICAMP Capítulo 3: Qualidade de Produto e a ISO 9126 Capítulo 1: Introdução Capítulo 2: Conceitos Básicos Capítulo 3: Qualidade de Produto (ISO9126) Capítulo 4: ISO9001 e ISO9000-3 Capítulo 5: CMM Capítulo 6:

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Rational Unified Process

Rational Unified Process Rational Unified Process Engenharia de Software Bruno Braun Fernando Coelho Jonatas Teixeira Vinicius Massuchetto Sobre o RUP Metodologia proprietária de desenvolvimento de software Iterativo e incremental

Leia mais

O Processo Unificado

O Processo Unificado UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo Unificado 879SCC Projeto e Desenvolvimento de Sistemas

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Engenharia de Requisitos- como Previnir e Reduzir Riscos

Engenharia de Requisitos- como Previnir e Reduzir Riscos Engenharia de Requisitos- como Previnir e Reduzir Riscos Natasha de Souza Arruda natasha.arruda@ig.com.br FGS Resumo:Engenharia de Requisitos é um dos processos fundamentais para o desenvolvimento de software.

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Curso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP

Curso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP Conceitos RUP RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo de Engenharia de software criado pela Rational Software Corporation(a qual foi incorporada pela

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução aos Processos de Software: modelos e ciclo de vida de software Prof. MSc. Hugo Vieira L. Souza Este documento está sujeito a copyright. Todos os direitos estão reservados

Leia mais

Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto

Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto Prof. Elias Batista Ferreira Material cedido por: Prof. Edison A M Morais Objetivo Descrever os processos da norma

Leia mais

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Unidade IV GERENCIAMENTO DE PROJETOS DE TI Agenda da disciplina Unidade I Gestão de Projetos Unidade II Ferramentas para Gestão de Projetos Unidade III Gestão de Riscos em TI Unidade

Leia mais

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software CCE 876 - Engenharia de Software Introdução à Engenharia de Software Objetivos Introduzir a Engenharia de Software e explicar sua importância. Introduzir os conceitos principais relacionados à Engenharia

Leia mais

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1 Qualidade Plácido A. S. Neto 1 1 Gerência Educacional de Tecnologia da Informação Centro Federal de Educação Tecnologia do Rio Grande do Norte 2006.1 - Planejamento e Gerência de Projetos Agenda Introdução

Leia mais

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SIG Aula N : 11 Tema: Como desenvolver e

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO MP1 DATA 05/03/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA

Leia mais

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO Capítulo 12 REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO 12.1 2003 by Prentice Hall OBJETIVOS De que forma o desenvolvimento de um novo sistema poderia mudar a maneira de uma organização trabalhar?

Leia mais

Modelos de Qualidade de Produto de Software

Modelos de Qualidade de Produto de Software CBCC Bacharelado em Ciência da Computação CBSI Bacharelado em Sistemas de Informação Modelos de Qualidade de Produto de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Leia mais

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos SOFTWARE PROCESSES Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos Introduzir modelos de processo de software Descrever uma variedade de modelos de processo

Leia mais

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004 Introdução ao RUP Rational Unified Process por Denize Terra Pimenta Outubro/2004 1 Contexto Não é suficiente apenas a presença de desenvolvedores altamente treinados: Precisamos de uma linguagem para a

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 VANT-EC-SAME Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 Histórico da Revisão Data Versão Descrição Autor 17/0/07 1.0 Versão Inicial Douglas Moura Confidencial VANT-EC-SAME, 2007

Leia mais

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 3 http://www.ic.uff.br/~bianca/engsoft2/ Aula 3-29/04/2006 1 Monitoria Marina Albuquerque E-mail: monitoriaes2@yahoo.com.br Horário de Atendimento: Terça e quinta de 09:00

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010 Engenharia de Software Aula 5 (Versão 2010-02) Melhores práticas para desenvolvimento de software Desenvolver de forma iterativa e gerenciar requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br

Leia mais

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO 1 OBJETIVOS 1. De que forma o desenvolvimento de um novo sistema poderia mudar a maneira de uma organização trabalhar? 2. Como uma empresa pode certificar-se

Leia mais

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás Prof.: Ivon Rodrigues Canedo PUC Goiás Qualidade Subjetiva Não sei o que é mas reconheço quando a vejo Qualidade Baseada no Produto O produto possui algo que produtos similares não têm Qualidade Baseada

Leia mais

Fábrica de Software 29/04/2015

Fábrica de Software 29/04/2015 Fábrica de Software 29/04/2015 Crise do Software Fábrica de Software Analogias costumam ser usadas para tentar entender melhor algo ou alguma coisa. A idéia é simples: compara-se o conceito que não se

Leia mais

ISO - 9126. Aécio Costa

ISO - 9126. Aécio Costa ISO - 9126 Aécio Costa A evolução da Qualidade do Produto Qualidade = funcionalidade Confiabilidade Realização de funções críticas Produto de qualidade = sem bugs Controle de qualidade Teste do produto

Leia mais

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita Unified Process Sueleni Mendez Batista Orientadora: Dra. Elisa Hatsue Moriya Huzita Processo de Desenvolvimento de Software 8O processo de desenvolvimento de software é um conjunto de atividades e resultados

Leia mais

CMM - Capability Maturity Model

CMM - Capability Maturity Model Tema da Aula Normas e Padrões de Qualidade em II CMM Prof. Cristiano R R Portella portella@widesoft.com.br CMM - Capability Maturity Model Desenvolvido pelo SEI (Instituto de Engenharia de ) Carnegie Mellon

Leia mais

GESTÃO DO CONHECIMENTO EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

GESTÃO DO CONHECIMENTO EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE GESTÃO DO CONHECIMENTO EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE RESUMO Carlos Eduardo Spolavori Martins 1 Anderson Yanzer Cabral 2 Este artigo tem o objetivo de apresentar o andamento de uma pesquisa

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas

Leia mais

Objetivos desta Aula. Introdução a Engenharia de Software Capítulo 1. Sumário. Engenharia de Software. Custos do Software. Custos do Software

Objetivos desta Aula. Introdução a Engenharia de Software Capítulo 1. Sumário. Engenharia de Software. Custos do Software. Custos do Software Objetivos desta Aula Introdução a Engenharia de Software Capítulo 1 Introduzir a engenharia de e explicar a sua importância Responder uma série de perguntas sobre engenharia de Introduzir questões éticas

Leia mais

CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação

CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação CobiT 5 Como avaliar a maturidade dos processos de acordo com o novo modelo? 2013 Bridge Consulting All rights reserved Apresentação Sabemos que a Tecnologia da

Leia mais

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK V EPCC Encontro Internacional de Produção Científica Cesumar 23 a 26 de outubro de 2007 METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK Cleber Lecheta Franchini 1 Resumo:

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais