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

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

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

! 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 à 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

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

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

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

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

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

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

Engenharia de Software-2003

Engenharia de Software-2003 Engenharia de Software-2003 Mestrado em Ciência da Computação Departamento de Informática - UEM Profa. Dra. Elisa H. M. Huzita eng. de software-2003 Elisa Huzita Produto de Software Conceitos Software

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

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

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

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

Desenvolvimento de Software requer Processo e Gestão

Desenvolvimento de Software requer Processo e Gestão Desenvolvimento de Software requer Processo e Gestão Antonio Mendes da Silva Filho * If Edison had a needle to find in a haystack, he would proceed at once with the diligence of the bee to examine straw

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE MODULO 3 SISTEMA DE GARANTIA DA QUALIDADE CONTEÚDO 3.1 A ABORDAGEM NBR ISO 9000 3.2 MODELOS DE QUALIDADE DE PRODUTO DE SOFTWARE 3.2.1 NBR ISO/IEC 9126 (SOFTWARE) 3.2.2 NBR ISO/IEC

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

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

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

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

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

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

RUP como Metodologia de Desenvolvimento de Software para Obtenção da Qualidade de Software

RUP como Metodologia de Desenvolvimento de Software para Obtenção da Qualidade de Software SEGeT Simpósio de Excelência em Gestão e Tecnologia 1 RUP como Metodologia de Desenvolvimento de Software para Obtenção da Qualidade de Software Alfredo Nazareno P. Boente Fabiano S. G. de Oliveira João

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

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO Danilo Freitas Silvas Sistemas de informação CEATEC danilofs.ti@gmail.com Resumo:

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

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

Engenharia de Software

Engenharia de Software Tema da Aula Modelos de Ciclos de Vida de 2 Outros Modelos Prof. Cristiano R R Portella portella@widesoft.com.br Ciclos de Vida de As duas primeiras décadas da ES foram dominadas pelo paradigma do desenvolvimento

Leia mais

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Qualidade de Software Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Ementa Conceitos sobre Qualidade Qualidade do Produto Qualidade do Processo Garantida da Qualidade X Controle da Qualidade Conceitos

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

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

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

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

Introdução Engenharia de Software

Introdução Engenharia de Software Introdução Engenharia de Software Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 EMENTA Parte 1 Conceitos de Engenharia de Software. Processo de desenvolvimento

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

Processos de Desenvolvimento de Software. Prof. Hélio Engholm Jr

Processos de Desenvolvimento de Software. Prof. Hélio Engholm Jr Processos de Desenvolvimento de Software Objetivos Descrever o processo de desenvolvimento de software Orientado a Objetos (Object Oriented Software Development - OOSD) Descrever como a modelagem suporta

Leia mais

Engenharia de Software: Metodologias e Contextualização. Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br

Engenharia de Software: Metodologias e Contextualização. Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br Engenharia de Software: Metodologias e Contextualização Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br Conceitos iniciais Informática: Ciência que tem como objetivo o tratamento da

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2 ENGENHARIA DE SOFTWARE II Modelos de Ciclo de Vida e Processos de Software AULA 2 Sumário Motivação Conceitos de Processo de Desenvolvimento de Software Atividades que compõem os processos de desenvolvimento

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

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

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

Processos de Desenvolvimento de Software. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 2

Processos de Desenvolvimento de Software. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 2 Processos de Desenvolvimento de Software Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 2 A Engenharia de Software Uma Tecnologia em Camadas ferramentas métodos processo foco na qualidade

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

Qualidade de Software

Qualidade de Software Qualidade de Software Introdução Qualidade é um dos principais objetivos da Engenharia de Software. Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção com qualidade. Tem-se

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

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

Segurança de Aplicações Aula 6

Segurança de Aplicações Aula 6 Segurança de Aplicações Aula 6 Prof. Msc. Anderson da Cruz Apresentação Atividade Apresentação da atividade realizada na aula 4 2 Desenvolvimento de Software 3 Modelos de Desenvolvimento de Software Cascata

Leia mais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais 2 Jogos Educacionais Jogos estão presentes como uma prática habitual, eles tem sido concebidos como uma atividade lúdica que é bastante motivadora no processo de ensinoaprendizado. É assim que jogos educacionais

Leia mais

pacotes de software na forma em que são É importante salientar que não é objetivo do software, suas atividades e produtos

pacotes de software na forma em que são É importante salientar que não é objetivo do software, suas atividades e produtos ISO/IEC 12119 ISO/IEC 12119 Et Esta norma é aplicável liá là avaliação de pacotes de software na forma em que são oferecidos e liberados para uso no mercado É importante salientar que não é objetivo desta

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Qualidade de Software

Qualidade de Software Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Qualidade de Software Desvendando um requisito essencial no processo de desenvolvimento

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

FACULDADE LOURENÇO FILHO ENADE 2011 Prof. Jackson Santiago Engenharia de Software DATA: 29/10/2011

FACULDADE LOURENÇO FILHO ENADE 2011 Prof. Jackson Santiago Engenharia de Software DATA: 29/10/2011 Assunto : Ciclo de vida de software 1. O modelo de ciclo de vida em cascata: a) enfatiza a realização sequencial das atividades do desenvolvimento de um produto de software. b) enfatiza a comunicação estreita

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

O Ciclo de Vida do Desenvolvimento de Sistemas i

O Ciclo de Vida do Desenvolvimento de Sistemas i O Ciclo de Vida do de Sistemas i O Ciclo de Vida do de Sistemas ( SDLC Systems Development Life Cycle), conhecido também com o ciclo de vida do software refere-se aos estágios de concepção, projeto, criação

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

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

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

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

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

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

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

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

Engenharia de Software Processo de Desenvolvimento de Software

Engenharia de Software Processo de Desenvolvimento de Software Engenharia de Software Processo de Desenvolvimento de Software Prof. Edison A. M. Morais prof@edison.eti.br http://www.edison.eti.br Objetivo (1/1) Conceituar PROCESSO E CICLO DE VIDA, identificar e conceituar

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 Desenvolvimento de Sistemas (Versão 2.0)

Metodologia de Desenvolvimento de Sistemas (Versão 2.0) SERVIÇO PÚBLICO FEDERAL MINISTÉRIO DA INTEGRAÇÃO NACIONAL DEPARTAMENTO NACIONAL DE OBRAS CONTRA AS SECAS Metodologia de Desenvolvimento de Sistemas (Versão 2.0) 1 Sumário 1Introdução... 5 1.1 Objetivo...

Leia mais

ENGENHARIA DE SOFTWARE II

ENGENHARIA DE SOFTWARE II UNIVERSIDADE FEDERAL DO MATO GROSSO ENGENHARIA DE SOFTWARE II Revisão dos principais conceitos da Engenharia de Software: Motivação; Histórico; Terminologia; Principais modelos de processos e métodos;

Leia mais

O USO DA NORMA 14598 NA AVALIAÇÃO DE SOFTWARE COM RELAÇÃO À QUALIDADE. Evaluation of Software With the use of Norm Iso 14598

O USO DA NORMA 14598 NA AVALIAÇÃO DE SOFTWARE COM RELAÇÃO À QUALIDADE. Evaluation of Software With the use of Norm Iso 14598 O USO DA NORMA 14598 NA AVALIAÇÃO DE SOFTWARE COM RELAÇÃO À QUALIDADE Evaluation of Software With the use of Norm Iso 14598 Walteno Martins Parreira Júnior, Izaura Pereira Pradela, Lucineida Nara de Andrade

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

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

Engenharia de Software

Engenharia de Software UFES - Universidade Federal do Espírito Santo Engenharia de Software Notas de Aula PARTE I E-mail: falbo@inf.ufes.br Curso: Engenharia da Computação (Atualizadas por e Monalessa Perini Barcellos - 2011)

Leia mais

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts

Leia mais

Processo de Desenvolvimento de Software

Processo de Desenvolvimento de Software Unidade IV Introdução aos Padrões de PDS Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo da Unidade 1. CMM / CMMI 2. SPICE 3. ISO 12207 4. MPS/BR CMM - Capability Maturity Model CMM Capability

Leia mais

Tecnologias Atuais de. Desenvolvimento de Software

Tecnologias Atuais de. Desenvolvimento de Software Tecnologias Atuais de Desenvolvimento de Software volução dos Processos de Desenvolvimento de Software Prof. Luiz Antônio lpereira@uninet.com.br Agenda onceitos volução dos Processos de Software Modelos

Leia mais