ESTUDO EXPLORATÓRIO UTILIZANDO BUSINESS PROCESS MANAGEMENT COMO FERRAMENTA DE AUXÍLIO ÀS PRÁTICAS DE ENGENHARIA DE REQUISITOS

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

Download "ESTUDO EXPLORATÓRIO UTILIZANDO BUSINESS PROCESS MANAGEMENT COMO FERRAMENTA DE AUXÍLIO ÀS PRÁTICAS DE ENGENHARIA DE REQUISITOS"

Transcrição

1 ESTUDO EXPLORATÓRIO UTILIZANDO BUSINESS PROCESS MANAGEMENT COMO FERRAMENTA DE AUXÍLIO ÀS PRÁTICAS DE ENGENHARIA DE REQUISITOS JULLIANE CRISTINNE MÁGERO ELIHIMAS Universidade Federal de Pernambuco RECIFE, 28 DE MARÇO DE

2 JULLIANE CRISTINNE MÁGERO ELIHIMAS ESTUDO EXPLORATÓRIO UTILIZANDO BUSINESS PROCESS MANAGEMENT COMO FERRAMENTA DE AUXÍLIO ÀS PRÁTICAS DE ENGENHARIA DE REQUISITOS Monografia apresentada ao Curso de pós-graduação em Ciência da Computação, Centro de Informática, Universidade Federal de Pernambuco, como requisito parcial para conclusão da disciplina Engenharia de Requisitos. Professor: Prof. Jaelson Brelaz de Castro Recife 28 de Março de

3 RESUMO Muitos softwares continuam sendo desenvolvidos sem a existência de uma visão completo do processo a ser automatizado em relação à estratégia de negócio da empresa. Na tentativa de mitigar e/ou eliminar os efeitos desta abordagem, tem-se utilizado os conceitos e ferramentas como Business Process Management (BPM), para auxiliar e apoiar às práticas de engenharia de requisitos. Neste sentido, o presente trabalho, visa apresentar a utilização do BPMN (Business Process Modelling Notation), nas distintas fases do Processo de Engenharia de Requisitos. Para atingirmos esse objetivo geral, o estudo apresenta o resultado de um levantamento bibliográfico sobre engenharia de requisitos e Business Process Management; realiza uma análise comparativa entre três estudos, procurando evidenciar as vantagens da utilização do BPM e por fim, destaca o Business Process Modeling Notation (BPMN) como um facilitador linguístico utilizado na validação dos processos e requisitos entre os analistas de sistemas e seus clientes ou usuários. Palavras-chave: Engenharia de Requisitos, Business Process Management, Business Process Modeling Notation. 3

4 ABSTRACT Many software still being developed without the existence of a complete overview of the process to be automated in relation to the company's business strategy. In an attempt to mitigate and / or eliminate the effects of this approach, we have used the concepts and tools such as Business Process Management (BPM), to assist and support the practice of requirements engineering. In this sense, the present work aims to present the use of BPMN (Business Process Modelling Notation) in the different phases of the requirements engineering process. To achieve this overall objective, the study presents the results of a literature on requirements engineering and Business Process Management, performs a comparative analysis of three studies, seeking to demonstrate the advantages of the use of BPM and finally highlights the Business Process Modeling Notation (BPMN) as a language facilitator used in the validation of procedures and requirements among systems analysts and their clients or users. Keywords: Engenharia de Requisitos, Business Process Management, Business Process Modeling Notation. 4

5 SUMÁRIO 1 INTRODUÇÃO ENGENHARIA DE REQUISITOS Conceitos Processo da engenharia de requisitos Problemas inerentes à engenharia de requisitos BUSINESS PROCESS MANAGEMENT (BPM) Conceitos Soluções e padrões inerentes ao BPM Business Process Modeling Notation (BPMN) Business Process Management System (BPMS) ESTADO DA ARTE DO BPM NA ENGENHARIA DE REQUISITOS Processos de engenharia de requisitos como processo de negócio Processo As Is Processo To Be Utilizando BPMN em um processo de engenharia de requisitos Processo As Is Processo To Be Integração de requisitos não-funcionais a processos de negócio CONSIDERAÇÕES FINAIS REFERÊNCIAS

6 LISTA DE FIGURAS Figura 1 Fases da engenharia de requisitos 12 Figura 2 Países e continentes de origem dos respondentes 19 Figura 3 Processo de ER Modelo As Is 25 Figura 4 Processo de ER - Modelo To Be 25 Figura 5 Processo de ER - Modelo As Is 30 Figura 6 Processo de ER - Modelo To Be 31 Figura 7 Abordagem BPMNFR 33 6

7 LISTA DE QUADROS Quadro 1 Fases da engenharia de requisitos 11 Quadro 2 Fases da engenharia de requisitos 12 Quadro 3 Fases da engenharia de requisitos 13 Quadro 4 Lista dos BPMS mais utilizados no mundo 22 Quadro 5 Abordagem Goal-Question- (Indicator)-Measure (GQ(I)M) 27 7

8 1 INTRODUÇÃO A informatização está invadindo todas as áreas das atividades humanas. Em vista disso, as empresas desenvolvedoras de software, software house estão, cada vez mais, tendo a responsabilidade de colocar nas prateleiras, softwares de qualidade que atendam realmente às necessidades dos usuários. Porém, ainda é comum encontrar durante o desenvolvimento dos softwares erros decorrentes do levantamento de requisitos até a implantação do sistema. Segundo Meira (2008), tais erros, podem ser oriundos de diversas questões técnicas, como por exemplo, uma programação mal feita, uma modelagem inadequada, a má comunicação entre as pessoas. Alguns autores (WHITE, 2005; BITENCOURT, 2008) apontam, como uma possível causa, o desenvolvimento de software sem a existência de uma visão holística do processo a ser automatizado, ou seja, sem o entendimento do papel do software em relação ao processo, estratégia e metas de negócio da empresa. Segundo Magela (2006), o usuário não tem tanta liberdade em definir os requisitos de um sistema simplesmente pela sua vontade. Cada requisito fornecido pelo usuário deverá ser validado contra os processos da empresa e sua política de negócio. Veríssimo (2007) diz que o levantamento de requisitos é umas das partes mais importantes no desenvolvimento de um sistema. Entender aquilo que o cliente deseja ou o que o cliente acredita que precisa e as regras do negócio ou processos do negócio. Isso é o cerne que move essa importante função que faz parte da engenharia de requisitos. Durante o desenvolvimento de muitos sistemas o custo e prazo são ultrapassados ou até mesmo morrem e não alcançam o seu objetivo, e muitas vezes isto ocorre devido o levantamento de requisitos ter sido feito de forma negligenciada ou simplesmente feita de forma ineficaz. Magela (2006), afirma que mais da metade dos defeitos de um software tem origem em erros cometidos no levantamento de requisitos. Destes erros 49% são de requisitos incorretos ou baseados em informações incorretas, 31% são de requisitos omitidos, 13% de requisitos inconsistentes, 5% de requisitos ambíguos e 2% outros. Na maioria dos casos foi o usuário que forneceu as informações incorretas, omitiu os requisitos ou que tornou o requisito inconsistente e ambíguo, tudo isso com base em receios internos ou desconhecimento real do negocio. 8

9 Em vista disto este projeto se justifica pela negligência relacionada à importância da obtenção de uma visão total do sistema a ser desenvolvido. Nestes termos, acredita-se que a utilização de Business Process Management como ferramenta de auxílio às práticas de engenharia de requisitos seja capaz de aumentar a qualidade e a precisão dos dados levantados e analisados pelos analistas de sistemas. Assim, a partir da visão geral sobre o sistema, pretende-se diminuir os retrabalhos gerados pelos pontos desconhecidos existentes no levantamento, análise e projeto de sistemas de informação. O objetivo geral desse estudo é explorar o estado da arte em relação à utilização do Business Process Management como ferramenta de auxílio às práticas de engenharia de requisitos. Para atingirmos esse objetivo geral devemos: realizar um levantamento bibliográfico sobre engenharia de requisitos e Business Process Management e realizar um levantamento bibliográfico sobre outros estudos de caso que utilizaram os conceitos e ferramentas do BPM como apoio a engenharia de requisitos. O presente estudo está estruturado da seguinte maneira: o primeiro capítulo apresenta os resultados obtidos através de uma revisão bibliográfica sobre Engenharia de Requisitos e Business Process Management (BPM). Este capítulo visa contextualizar e formar a base desta pesquisa, a qual descreve os principais conceitos, ferramentas e limitações da engenharia de requisitos. Por fim, discutimos as nuances dos Business Process Management System (BPMS) e Business Process Modeling Notation (BPMN). No segundo capítulo, elencamos alguns estudos que abordam o processo de engenharia de requisitos utilizando conceitos de ferramentas do BPM, tais como: BPMS e BPMN. Nas considerações finais do trabalho, apresentamos as principais lições aprendidas através da análise dos trabalhos de engenharia de requisitos que utilizaram os conceitos e ferramentas do BPM como auxiliar na elicitação e validações dos requisitos pelos analistas de sistemas e seus clientes ou usuários. 9

10 2 ENGENHARIA DE REQUISITOS Nesta seção serão apresentados os conceitos referentes à engenharia de requisitos, bem como seu processo, problemas e soluções propostas por vários estudiosos. 2.1 Conceitos O termo engenharia de requisitos, segundo Kotonya (1998) tem o propósito de abranger todas as atividades envolvidas no descobrimento, documentação e manutenção de um conjunto de requisitos. Pode-se afirmar que a engenharia de requisitos substitui a denominação clássica análise de sistemas, a qual não reflete, de forma adequada, todas as atividades envolvidas no tratamento dos requisitos de um sistema de software. Zave (1995) define a engenharia de requisitos como a área da engenharia de software preocupada com os objetivos do mundo real, funções e condições sobre software. Também se refere ao relacionamento destes fatores para especificações de comportamento de software, para evolução do software como tempo o cruzamento de famílias de software (comportamentos de dados e funções). A engenharia de requisitos para Sommerville (1997) é um termo relativamente novo que foi inventado para cobrir todas as atividades envolvidas em descobrimento, documentação e manutenção e um conjunto de requisitos para um sistema baseado em computador. Em resumo, a engenharia de requisitos pode ser compreendida como o processo de desenvolvimento de requisitos de sistema. Embora existam visões um pouco variadas sobre as atividades que compõem a engenharia de requisitos, podemos dividi-la nas seguintes atividades elicitação, análise, especificação, validação e gerenciamento. Cada uma dessas atividades constitui um processo próprio, com objetivos bem definidos [KOTONYA, 1998]. A análise da engenharia de requisitos é desenvolvida sob a ótica do desenvolvedor e do usuário. Do ponto de vista do analista/desenvolvedor, a engenharia de requisitos refere-se ao que o sistema deve fazer e não ao como deve fazê-lo. Está associada, portanto, a uma situação futura, sobre a qual deve ser capaz de fazer previsões e analisar alternativas [LOPES, 1999]. A engenharia de requisitos procura sistematizar o processo de definição de requisitos. Essa sistematização é necessária porque a complexidade dos sistemas exige 10

11 que se preste mais atenção ao correto entendimento do problema antes do comprometimento de uma solução [CORDEIRO, 2002]. Segundo Sommerville (2003), os engenheiros de software acreditam que compreender com exatidão o que o sistema deve ter, na maioria das vezes, pode ser imensamente complexo, especialmente quando o sistema for novo. Portanto, foi necessário desenvolver técnicas para tentar aumentar a precisão e o entendimento das necessidades dos clientes e, principalmente, dos usuários. Pressman (2006) corrobora com esta visão, afirmando que a engenharia de requisitos surgiu para auxiliar os engenheiros de software a entender melhor o problema que eles tentarão resolver. Além disso, explica que tal compreensão é subsidiada por um conjunto de tarefas que levam a um entendimento sobre o impacto do software no negócio do cliente. Sommerville (2003) explica que a engenharia de requisitos surgiu para facilitar o entendimento dos requisitos, que nada mais é que a descrição das funções e das restrições do sistema. Neste sentido, Pfleeger (2004) conceitua requisitos como: as características do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos. Por outro lado, Magela (2006), defende que requisitos é um conjunto de sentenças condicionadas pelos processos e pela política de negócio da empresa que visam definir as funcionalidades que devem existir em um software. Paula Filho (2001), explica que a engenharia de requisitos pode ser definida como a disciplina que reúne um conjunto de técnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto de software. E as atividades de requisitos compreendem as atividades que visam obter o enunciado completo, claro e preciso dos requisitos de um produto de software. A engenharia de requisitos, segundo Thayer (1997 apud Belgamo), é a primeira etapa dentro de todo o processo da engenharia de software, a qual estuda como coletar, entender, armazenar, verificar e gerenciar os requisitos. Thayler menciona que a principal preocupação na engenharia de requisitos é entender quais são os reais requisitos do sistema, bem como, a documentação dos mesmos. Magela (2006) defende que a engenharia de requisitos é de extrema importância, pois, projetar e construir um programa de computador elegante que resolva o problema errado não serve às necessidades de ninguém. Logo, é importante entender o que o cliente deseja antes de começar a projetar e construir um sistema baseado em computador. 11

12 requisitos. Em vista disto, a próxima sessão irá detalhar o processo de engenharia de 2.2 Processo da engenharia de requisitos Como visto na seção anterior, a engenharia de requisitos nada mais é do que um processo para ajudar os engenheiros de software a compreender o que o cliente espera de um sistema. O termo análise de requisitos ou engenharia de requisitos, segundo Stokes (2003 apud Da Silva), refere-se a uma coleção dos processos de extração, especificação, verificação e validação, apresentados em 04 passos subsequentes, no Quadro 1. Quadro 1 Fases da engenharia de requisitos Fonte: Stokes (2003 apud Da Silva) Para Sommerville (2003), a engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições de um sistema. Tal processo é realizado através das tarefas de elicitação, análise e negociação, documentação e validação dos requisitos, conforme Figura 1. Na Figura 1 são apresentas 04 fases do processo de engenharia de requisitos. Na primeira fase, denominada elicitação de requisitos, os engenheiros de software descobrem através de consultas com o cliente o que ele deseja do sistema. Na segunda fase, denominada análise e negociação de requisitos, os requisitos são analisados e os conflitos resolvidos através de negociação com o cliente. Posteriormente, na terceira fase, produz-se a documentação de requisitos. Por fim, na quarta e última fase, a qual é 12

13 denominada validação de requisitos, realiza-se a checagem da consistência e completude do documento de requisitos. Figura 1 - Fases da engenharia de requisitos Fonte: Sommerville (2003) A partir de uma linguagem mais gerencial, Thayer (1997 apud Belgamo) define as fases da engenharia de requisitos como: elicitação, análise, especificação, verificação e gerenciamento. O detalhamento e descrição de cada fase é mostrado no Quadro 2. Quadro 2 - Fases da engenharia de requisitos Fonte: Thayer (1997 apud Belgamo) 13

14 O processo de engenharia de requisitos pode ser compreendido como uma sequência de atividades: articulação do conceito inicial, análise de problema, viabilidade e escolha de opções, análise e modelagem e documentação de requisitos [MACAULAY 1996]. Cada atividade requererá o uso de técnicas potencialmente diferentes, conforme Quadro 3. Quadro 3 - Fases da engenharia de requisitos Fonte: Macaulay (1996) Apesar dos autores Stokes (2003 apud Da Silva), Sommerville (2003) e Thayer (1997 apud Belgamo) apresentarem as fases da engenharia de requisitos com quantidades e termos diferentes, a descrição de cada fase leva a crer que todos os autores corroboram com a visão de [Macaulay 1996]. Poucas organizações têm um processo de engenharia de requisitos padronizado e definido explicitamente. A aplicação varia de uma organização para outra, mas muitos processos envolvem as atividades de: extração, análise e negociação, documentação e validação de requisitos. O funcionamento ocorre de modo espiral, é iterativo e envolve repetições das atividades na geração de versões do documento de requisitos. Entretanto, destaca-se que o uso inadequado das técnicas, documentos e ferramentas da engenharia de requisitos tem gerado vários problemas, os quais são capazes de afetar a qualidade do produto final de um projeto de software. Por isso, a próxima seção abordará alguns problemas inerentes a cada fase da engenharia de software. 14

15 2.3 Problemas inerentes à engenharia de requisitos Estudos mostram que os principais problemas associados ao insucesso dos projetos de software estão relacionados à etapa de engenharia de requisitos [THE STANDISH GROUP 1995; EUROPEAN SOFTWARE INSTITUTE 1996]. Outro ponto importante é que quanto mais tarde problemas com requisitos são detectados no processo de desenvolvimento, maior é o custo para corrigi-los. O sucesso das etapas posteriores do processo de desenvolvimento depende da qualidade da especificação de requisitos gerada [LEFFINGWELL 2000]. Por estas razões a engenharia de requisitos é classificada como uma das fases mais críticas do desenvolvimento de software. Tradicionalmente, os principais problemas associados às especificações de requisitos são [KOTONYA 1998]: os requisitos não refletem as reais necessidades do usuário; os requisitos são inconsistentes, incompletos e/ou ambíguos; é dispendioso fazer mudanças após os requisitos terem sido acordados; e é comum ocorrer diferenças de interpretação entre clientes e equipe de desenvolvimento. Tais problemas surgem principalmente devido a dificuldades relacionadas à comunicação com os usuários. Estudos empíricos em diversas fábricas de software demonstram que o envolvimento do usuário é fator essencial para um processo de engenharia de requisitos de qualidade e, consequentemente, para o sucesso dos projetos de software em geral [HOFMANN 2001; KUJALA 2005]. Contudo, é sabido que, na maioria dos casos, os usuários não conseguem descrever em uma entrevista os seus próprios problemas organizacionais e sociais, não sabem identificar o que ele necessita de um sistema de software, e muitas vezes não possui aptidão para expor claramente suas ideias [GOGUEM 1994; HALMER 2000]. Martins (s/d) categoriza os problemas na elicitação de requisitos em três grupos: o o Problemas de escopo O limite do sistema não é bem definido; Informações desnecessárias de projeto podem ser fornecidas (tipicamente informações sobre o desenho do software). Problemas de entendimento Ambiguidade na especificação dos requisitos; Usuários têm entendimento incompleto de suas necessidades; Usuários conhecem pouco sobre a capacidade e limitações de computadores; Analistas têm pouco conhecimento sobre o domínio do problema; 15

16 o Usuários e analistas falam línguas diferentes; Omissão de informações óbvias ; Visões conflitantes entre os usuários; Requisitos frequentemente vagos e não-testáveis; Problemas de volatilidade Requisitos evoluem no tempo (em conseqüência de): Maior clareza do usuário em relação ao sistema; Mudanças no negócio; Mudanças tecnológicas; Segundo Van Lamsweerde (2000 apud Meira, 2008) por causa da persistência destes problemas, a engenharia de requisitos atrai muito interesse e investimento. Entretanto, destaca que melhorar a qualidade dos requisitos é um dos caminhos para garantir o sucesso dos projetos, porém é um objetivo difícil para alcançar. Nestes termos, Van Lamsweerde (2000 apud Meira, 2008) elenca algumas razões para que o processo de requisitos seja tão complexo. O escopo é regularmente amplo com níveis que variam de um mundo de organizações humanas ou leis físicas para um mundo de artefatos técnicos que devem estar integrados; de objetivos de alto nível para prescrições operacionais; e de informal para formal. O sistema alvo não é só uma peça de software, mas está embutido em um ambiente que deve ser considerado. Este último é composto de humanos, dispositivos e outros softwares. E, além disso, o sistema todo deve ser considerado sobre várias facetas: socioeconômica, física, técnica, operacional, legal, evolucionária, entre outras. Existem múltiplos conceitos por detrás dos funcionais que devem ser analisados: segurança, usabilidade, flexibilidade, desempenho, robustez, interoperabilidade, custo, manutenibilidade, entre outros. Estes são conhecidos como requisitos não funcionais do sistema e geralmente existem muitos conflitos entre eles. Existem muitas partes envolvidas no processo de engenharia de requisitos, cada tendo diferente base, habilidade, conhecimento, interesse, percepção, entre outros. E, além disso, estas partes têm visões conflitantes na maioria das vezes. 16

17 Diante dos problemas advindos da engenharia de requisito, Verissímo (2007) enfatiza que aliado ao levantamento de requisitos, deve existir um mapeamento dos processos, pois isto é de extrema importância para a melhoria dos resultados obtidos pelo levantamento de requisitos. Magela (2006) não acredita na capacidade da análise de sistema em garantir a devida proteção às mudanças constantes do negócio, pois geralmente a análise esta fundamentada em conceitos frágeis oriundos de um levantamento de requisito frágil. Magela (2006) preconiza que a solidez dos artefatos gerados pela união das fases de requisitos e negócio potencializa o alcance e a eficácia da fase de análise de negócio ou processo da empresa que irá implantar o sistema que será desenvolvido. Logo, a fase de análise de negócio endereça as questões de processo e as regras contidas na política de negócio da empresa e, portanto, fornece a infraestrutura necessária para garantir que as vigas e amarras do sistema sejam construídas solidamente, ou seja, um levantamento de requisitos mais confiável. Nesta mesma concepção, Takai (2006) defende que o entendimento sobre onde os sistemas serão implantados, quem irá utilizá-los, como serão integrados aos sistemas existentes e o quê irá automatizar é a chave para o sucesso dos sistemas de informações. Assim, Magela (2006) avulta que o interesse pelo processo se dá, pelo fato de que eles são os portadores do verdadeiro impulso que move a empresa e que contém em si as regras da política de negócio que futuramente serão informatizadas. De modo complementar, Shishkov (2002 apud Teixeira) explica que os sistemas de informação são desenvolvidos para apoiar um negócio ou parte dele. Por isso, surgiu a abordagem chamada Business Process Management (BPM), a qual se baseia no levantamento e análise dos processos de negócio ao qual o sistema deve atender antes de se começar o projeto do sistema. Neste sentido, Teixeira (2006) afirma que a modelagem de negócio é uma técnica que veio pra auxiliar os analistas, na coleta exata de requisitos de uma empresa, com o objetivo de suprir todas as necessidades da mesma. A abordagem responsável pelo gerenciamento do processo do negócio de uma empresa será abordada na próxima seção. 17

18 3 BUSINESS PROCESS MANAGEMENT (BPM) Garimella (2008) afirma que o Business Process Management (BPM) não é nenhuma novidade, no entanto Pereira (2008) defende que o BPM é um conceito relativamente novo. Entretanto, ambos concordam que o BPM vem ganhando cada vez mais espaço no ambiente corporativo para se tornar mais uma tendência de gestão empresarial e de tecnologia da década. Nestes termos, esta seção discutirá os conceitos, ferramentas e filosofias que sustentam a adoção do BPM nas organizações e, principalmente, no desenvolvimento de sistemas de informação. 3.1 Conceitos A Gestão de Processos de Negócio (BPM) é uma abordagem disciplinada para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar Processos de Negócio para alcançar os resultados pretendidos consistentes e alinhados com as metas estratégicas de uma organização [CBOK 2009] Para Paim (2009), o Gerenciamento de Processos de Negócio (em inglês Business Process Management ou BPM) é um conceito que une gestão de negócios e tecnologia da informação com foco na otimização dos resultados das organizações por meio da melhoria dos processos de negócio. São utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação. Segundo Capote (2011), a modelagem de processos de negócio nada mais é que um conjunto de atividades necessárias para a criação de representações de processos existentes, ou que ainda estão em planejamento ou sendo projetados. Uma característica bastante marcante sobre a modelagem de processos de negócio, conforme a própria definição do tipo do processo denota, é que este tipo de modelagem deve contemplar e cobrir os processos de forma completa, ou, de ponta-a-ponta. Pereira (2008) define Business Process Management (BPM) como uma nova forma de gerir os negócios da empresa, por meio de um conjunto de práticas de gerenciamento de processos que os tornam mais eficazes, eficientes e alinhados com as estratégias e a cadeia de valor das organizações. Analogamente, Garimella (2008) conceitua o BPM como um conjunto de métodos, ferramentas e tecnologias usadas para projetar, implementar, analisar, realizar controle operacional e controle de processos de negócio. 18

19 BPM é o enfoque disciplinado para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio, automatizados ou não, para alcançar resultados consistentes e alinhados com os objetivos estratégicos da organização, destaca Furlan (2008). Na concepção de Teixeira (2004), os objetivos da modelagem de negócios podem ser resumidos em: a) Compreender a estrutura e a dinâmica da organização na qual um sistema de informação será implantado; b) Compreender os principais problemas atuais da organização e identificar melhorias potenciais; c) Garantir que clientes, usuários e desenvolvedores tenham um entendimento comum sobre a organização; d) Apoiar na identificação dos requisitos do sistema que irá apoiar a organização. 3.2 Soluções e padrões inerentes ao BPM Pereira (2008) enfatiza que as soluções tecnológicas disponibilizadas pela tecnologia da informação nos últimos anos criaram a base necessária para a efetividade na utilização do BPM. Dentre as diversas soluções, cita as seguintes: Business Process Modeling Notation (BPMN), Business Process Management System (BPMS), Business Process Execution Language (BPEL) e Service Oriented Architecture (SOA). Nas próximas seção serão apresentados os conceitos e aplicações apenas do BPMN e BPMS, pois o BPEL e SOA não fazem parte do escopo deste trabalho Business Process Modeling Notation (BPMN) A notação para a modelagem de processo de negócios, BPMN, é uma notação padrão para o desenho de fluxogramas em processos de negócios. Na prática, trata-se de um conjunto de regras e convenções que determinam como os fluxogramas devem ser desenhados. Seu principal objetivo é prover uma notação com interface amigável e que seja compreendida por todos os usuários envolvidos, desde os analistas de negócios até os analistas de sistemas, preconiza [Stephen 2006]. Para Bortolini (2006), BPMN é uma especificação para modelagem visual de processos. O objetivo do BPMN é prover uma interface simples e poderosa que possa ser tanto utilizada por analistas de negócios quanto por analistas de sistemas, funcionando como um contrato entre as partes. 19

20 Pereira (2008) explica que a simbologia utilizada pelo BPMN permite a especificação dos fluxos num nível de detalhamento próximo da complexidade de um ambiente real. Desta forma, facilita a comunicação entre analistas e usuários, bem como as análises necessárias para a preparação da versão inicial do processo ou melhorias a serem realizadas. Recker (2008) realizou uma pesquisa de campo para determinar onde e por quem o BPMN está sendo utilizado. Em relação à distribuição geográfica do uso de BMPN, como é mostrado na Figura 2, a Europa, América do Norte e Oceania foram responsáveis por quase ¾ de todas as respostas. Quase 60% dos respondentes trabalham para empresas privadas e mais de 40% trabalham em organizações de grande porte com mais de 1000 empregados. Figura 2 Países e continentes de origem dos respondentes Em relação ao objetivo ou ramo de negócio mais utilizado pelo BPMN, Recker (2008) verificou que 51% dos respondentes iniciaram o uso do BPMN para melhorar seu negócio (documentação do processo, melhoria, análise de negócio, comunicação com stakeholders etc.) enquanto que 49% usaram o BPMN para propósitos mais técnicos (simulação de processo, análise de serviços e engenharia relacionada ao fluxo do trabalho). 20

21 A notação BPMN, segundo o BPMI, consiste de um diagrama, chamado Business Process Diagram (BPD). O BPD é concebido a partir de um conjunto de elementos gráficos que compõem diagramas simples de serem desenvolvidos e compreendidos. A especificação completa BPMN define mais de 50 atributos, agrupados em quatro categorias básicas de elementos: Flow Objects; Connecting Objects; Swim-lanes; e, Artefacts. Flow Objects, tais como eventos, atividades (que também podem ser macroprocessos) e gateways, são os elementos mais básicos usados para criar modelos BPMN. Connecting Objects são usados para interconectar Flow Objects através de diferentes tipos de setas. Swimlanes são usados para agrupar as atividades em categorias separadas para diferentes capacidades funcionais ou responsabilidades (por exemplo, papéis diferentes departamentos ou organizacional). Artefatos (Artefacts) podem ser adicionados a um modelo onde for considerado adequado, a fim de exibir mais informações relacionadas, tais como dados processados ou outros comentários. A notação BPMN tem como principal vantagem a fácil compreensão de seus modelos por todos os atores envolvidos no processo de desenvolvimento de um sistema. Porém, não são demonstrados de forma explícita os requisitos de qualidade (não funcionais). Bortolini (2006, p. 2) defende que o BPMN parece ser a única unanimidade: é apoiado por todos os grandes players e não possui nenhuma outra especificação concorrente. Além disso, destaca que na prática, o BPMN consiste em uma série de padrões de representação gráfica e de lógica no desenho de processos. Por isso, existem diversas ferramentas de desenhos de fluxos, conhecidos como BPMS, que incorporaram o padrão BPMN e, devido a sua simplicidade, tem todas as condições de no futuro ser utilizado pelos usuários finais Business Process Management System (BPMS) Quanto ao Business Process Management System (BPMS), Oliveira (2007) destaca que nos dois últimos anos, uma proposta que vem ganhando força é o desenvolvimento de sistemas de informação segundo uma metodologia de desenho e implementação, fundamentada no conceito de processos. Estes sistemas altamente flexíveis estão sendo chamados de BPMS, por criarem o arcabouço de TI necessário para suportar a aplicação do conceito de BPM na organização. 21

22 De acordo com Pereira (2008), o BPMS é uma categoria de software usada para apoiar a implantação e a execução dos processos sob a ótica do BPM. O BPMS permite realizar o mapeamento dos processos ponta-a-ponta, desenho dos fluxos e formulários eletrônicos, definição de regras de negócio, monitoramento em tempo real das atividades através de métricas preestabelecidas e alertas para a gestão. BPMS pode ser implantado numa organização, interagindo com aplicações (software) existentes ou independente destas. Segundo Sancovschi (1999, apud Oliveira, 2007), a fase do BPMS corresponderia à terceira onda do BPM. Para ele a primeira seria a Administração Científica, no qual os processos eram implícitos nas práticas de trabalho e não eram automatizados. A segunda seria a reengenharia, em que os processos eram melhorados manualmente e posteriormente automatizados. A terceira fase, seria o uso de BPMS, os quais permitem realizar simulações e prospecções do processo de negócio, seja ele o processo atual (AS-IS) ou o processo proposto (TO-BE). Nesta última fase, os processos são o foco central do desenvolvimento dos novos sistemas, permitindo que as organizações se tornem mais ágeis e possam ser continuamente otimizadas. No intuito de apresentar os principais aplicativos (BPMS) utilizados, Recker (2008), realizou uma pesquisa com 590 usuários de BPM distribuídos pelo mundo todo, e compilou uma lista com suas, respectivas, frequências, a qual é apresentada no Quadro 4. Como se pode notar no Quadro 4, a diferença entre a frequência do primeiro lugar Microsoft Visio (18,2%) para o segundo lugar itp-commerce Process Modeler (7,8%) é substancial. Entretanto, Recker (2008) ressalta que o Microsoft Visio não é uma ferramenta BPMS, pois é um ótimo editor gráfico mas não possui todas as funcionalidades requeridas para ser um BPMS completo. Neste caso, Recker (2008), postula que existem outras opções disponíveis, como é o caso da solução do Itp- Commerce que é um plug-in capaz de estender a capacidade de modelagem do Microsoft Visio com uma máquina de simulação baseada no BPMN, atributos adicionais e opções de análises. 22

23 Quadro 4 Lista dos BPMS mais utilizados no mundo Fonte: Recker (2008) Relacionado às várias opções de aplicativos disponíveis no mercado, aponta-se o trabalho de Oliveira (2007) que realizou um estudo de caso utilizando a ferramenta IDS Scheer ARIS como BPMS. Por fim, Recker (2008) destaca que os fornecedores SparxSystems, Telelogic, Intalio, IDS Scheer and Casewise oferecem soluções BPM que vão muito além das simples capacidades de modelagem de processos. Pereira (2007) destaca que na visão de Ismael Ghalimi, CEO da Intalio, um BPMS completo teria no mínimo os seguintes módulos ou funcionalidades: a. Ferramenta de modelagem e desenho do processo b. Engenho de execução do processo c. Orquestração de web services d. Interface de workflow para usuários 23

24 Para ter um produto mais completo, seria necessário: a. Suporte para regras de negócio complexas b. Business Activity Monitoring (BAM) c. Controle de versão dos documentos anexados a instâncias do processo E para um produto completo, seria acrescentado: a. Enterprise Service Bus (ESB) b. Repositório de metadados c. Uma suite de business intelligence No que refere-se às ferramentas consideradas BPMS, de la Vara e Sánches (2008); de la Vara, Sánches e Pastor (s/d); Oliveira (2007) realizam um apanhado das principais apontando os pontos fortes e pontos fracos de cada uma. Por fim destacam as ferramentas ARIS e B-SCP como as mais adequadas para o uso de BPM. 24

25 4 ESTADO DA ARTE DO BPM NA ENGENHARIA DE REQUISITOS Como foi apresentada no Capítulo 2, a engenharia de requisitos pode ser dividida em cinco partes: elicitação, análise, especificação, verificação e gerenciamento de requisitos. Porém, alguns autores (MAGELA, 2006; TAKAI, 2006) defendem a aplicação da análise de negócio antes da elicitação e análise de requisitos, pois tal prática visa garantir o alinhamento do software a ser desenvolvido com as estratégicas e metas do negócio da organização cliente. Apesar de existir o padrão de modelagem de negócio (BPMN) e diversos sistema que suportam tal modelagem (BPMS), apresentados no Capítulo 3, muitos analistas de negócio e analistas de sistemas estão buscando diferenciais competitivos na forma como tais recursos são utilizados. Nestes termos, a seguir serão apresentadas três abordagens distintas que utilizam o Business Process Management (BPM) como ferramenta de auxílio às práticas de engenharia de requisitos. 4.1 Processos de engenharia de requisitos como processo de negócio O trabalho de Cardoso (2012) procurou estabelecer visualização do processo de Engenharia de Requisitos (ER) como um processo de negócio, possibilitando a introdução de princípios de Gestão de Processos de Negócio (BPM) para sua melhoria. Como modelo de partida (As Is), considera-se o processo de ER, conforme [SWEBOK 2004]. Em seguida um processo desejável (To Be) é modelado, introduzindo-se princípios que proporcionam um aumento de efetividade e qualidade. A elevação da efetividade é obtida pelo gerenciamento estratégico, enquanto a melhoria da qualidade, pelo gerenciamento quantitativo. O autor utilizou um conjunto de princípios considerados fatores chaves de BPM, dentre eles a modelagem dos processos As Is e To Be, que corresponde às fases de Análise e Desenho do ciclo de vida BPM (CBOK, 2009), como forma de sistematização para a elaboração do processo proposto Processo As Is A abordagem utilizada por Cardoso (2012) foi de caráter genérico, optou-se, partir de um processo tradicional de ER em conformidade com o guia SWEBOK (2004). Esta opção proporciona maior flexibilidade, podendo ser utilizada por equipes, projetos e processos de software com características diversas. A figura 3 mostra o diagrama BPMN do processo As Is cujo modelo segue a proposta do Wiegers (2003). 25

26 Figura 3 - Processo de ER Modelo As Is O modelo As Is, por estar baseado nas abordagens tradicionais, pode apresentar problemas organizacionais identificados em outras pesquisas (BEECHAM et al, 2003 e SOLEMON et al, 2009a). São problemas relacionados com a falta de uma gestão efetiva do processo de ER, para os quais a presente abordagem propõe uma solução alternativa descrita na seção seguinte Processo To Be O processo To Be, modelado de acordo com a figura 4, deve possuir um conjunto de atividades que elevem seu desempenho, cujo foco está voltado apenas para as questões da efetividade e da qualidade. Figura 4 - Processo de ER - Modelo To Be. 26

27 O autor sugere a inserção de alguns princípios BPM para aumentar a efetividade do processo To Be, são eles: i. o alinhamento estratégico de negócio; ii. a designação de patrocínio executivo; iii. definição clara de propriedade do processo. O alinhamento estratégico, além da clara contribuição para efetividade do processo, foi incluído na extensão por ser um princípio fundamental, fazendo parte da própria definição de BPM. Quanto à definição dos papéis de patrocinador e dono, a escolha, se deu em virtude da grande contribuição desses papéis para a correta execução das atividades do processo, com consequente aumento da efetividade do processo. Almejando o alinhamento dos requisitos do sistema com a estratégia de negócio da organização (grupo de atividades superior), faz-se necessário acrescentar duas atividades: o alinhamento organizacional e o alinhamento de negócios. Para a primeira, que objetiva a obtenção dos requisitos organizacionais, existem algumas linguagens como i* e KAOS que podem auxiliar esta atividade. Quanto à segunda, que visa obter os requisitos do processo de negócio, podem-se utilizar técnicas que trabalham com metas. Visando elevar a perspectiva de qualidade, esta abordagem propõe a introdução da Gerência de Desempenho (grupo inferior da figura 4), que proporcionará um controle sobre a execução do processo de ER possibilitando a identificação de problemas. Para nortear esse gerenciamento optou-se em seguir as orientações contidas no trabalho Campos et al (2007), por apresentar uma proposta para implantação do SPC especificamente em um processo de Desenvolvimento de Requisitos. Na atividade de Medição são utilizados os princípios da abordagem Goal- Question-(Indicator)-Measure (GQ(I)M) para a especificação das medidas e indicadores. No quadro 5 são apresentadas as metas, questões, medidas e indicadores para o processo To Be. No Monitoramento, executada pelo dono do processo, medidas da execução do processo devem ser coletadas. Além das medidas básicas especificadas, devem ser registradas informações de caracterização dos projetos, tais como o tamanho total estimado, perfil da equipe do projeto, ambiente de desenvolvimento e versão do processo. Outra tarefa consiste na geração dos indicadores de desempenho; após coletar 27

28 as medidas básicas, as medidas derivadas podem ser calculadas para cada objetivo de interesse. Somente após calcular sucessivas medidas derivadas pode-se iniciar a elaboração do indicador estatístico, que é baseado em gráficos de controle. Para o Controle, partindo dos dados provenientes do monitoramento, inicialmente é feita a identificação das causas especiais de variação através dos gráficos de controle. Os pontos fora dos limites são os principais candidatos a estudo para identificação das causas especiais. Para análise desses pontos devem ser utilizados dados de contexto associados à medição, bem como avaliações de adequação de atividades. Quadro 5 Abordagem Goal-Question-(Indicator)-Measure (GQ(I)M) Fonte: Cardoso (2012) Apesar das restrições impostas pelo limite de escopo da pesquisa, observa-se que a proposta apresenta uma grande contribuição que é a possibilidade de introdução dos diversos conceitos de BPM a processos tradicionais de ER baseado no SWEBOK. Além disso, foi possível reunir sistematicamente algumas das principais abordagens da ER existentes sob a ótica de BPM, no caso da introdução do alinhamento estratégico. Outra contribuição da proposta consiste na introdução da gerência quantitativa em processos instáveis. Apesar dessa introdução ser motivo de discussão entre 28

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

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

Requisitos de Software

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

Leia mais

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira 3º semestre CONCEITOS CONCEITOS Atividade Ação executada que tem por finalidade dar suporte aos objetivos da organização. Correspondem

Leia mais

Autor(es) BARBARA STEFANI RANIERI. Orientador(es) LUIZ EDUARDO GALVÃO MARTINS, ANDERSON BELGAMO. Apoio Financeiro PIBIC/CNPQ. 1.

Autor(es) BARBARA STEFANI RANIERI. Orientador(es) LUIZ EDUARDO GALVÃO MARTINS, ANDERSON BELGAMO. Apoio Financeiro PIBIC/CNPQ. 1. 19 Congresso de Iniciação Científica ESPECIFICAÇÃO E IMPLEMENTAÇÃO DE UMA FERRAMENTA AUTOMATIZADA DE APOIO AO GERSE: GUIA DE ELICITAÇÃO DE REQUISITOS PARA SISTEMAS EMBARCADOS Autor(es) BARBARA STEFANI

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

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

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

A utilização de Business Process Modeling como ferramenta de auxílio às práticas de engenharia de requisitos

A utilização de Business Process Modeling como ferramenta de auxílio às práticas de engenharia de requisitos A utilização de Business Process Modeling como ferramenta de auxílio às práticas de engenharia de requisitos ANA CAROLINA ORAN FONSECA E TOLEDO Universidade Federal de Pernambuco posgraducao@cin.ufpe.br

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

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

Gerenciamento de Processos de Negócio

Gerenciamento de Processos de Negócio Gestão por Processos By Alan Lopes +55 22-99202-0433 alopes.campos@mail.com http://prof-alan-lopes.weebly.com Gerenciamento de Processos de Negócio - Conceitos e fundamentos - Modelagem de processo - Análise

Leia mais

Treinamento BPM e BPMN Apresentação Executiva

Treinamento BPM e BPMN Apresentação Executiva Apresentação Executiva 1 O treinamento de BPM e BPMN tem como premissa capacitar o aluno a captar as atividades relativas a determinado processo da empresa, organizá-las, gerando um fluxograma de atividades/processos,

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Engenharia de Software

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

Leia mais

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

Metodologia de Desenvolvimento de Sistemas

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

Leia mais

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

EXPERIÊNCIA DE USO DE ARQUITETURA CORPORATIVA NO PROJETO DE RES

EXPERIÊNCIA DE USO DE ARQUITETURA CORPORATIVA NO PROJETO DE RES EXPERIÊNCIA DE USO DE ARQUITETURA CORPORATIVA NO PROJETO DE RES Rigoleta Dutra Mediano Dias 1, Lívia Aparecida de Oliveira Souza 2 1, 2 CASNAV, MARINHA DO BRASIL, MINISTÉRIO DA DEFESA, BRASIL Resumo: Este

Leia mais

silviaheld@usp.br Italiano, Isabel Cristina. Profa. Dra. - Têxtil e Moda - Escola de Artes, Ciências e RESUMO ABSTRACT

silviaheld@usp.br Italiano, Isabel Cristina. Profa. Dra. - Têxtil e Moda - Escola de Artes, Ciências e RESUMO ABSTRACT MAPEAMENTO DE PROCESSOS DE CONFECÇÃO PARA IDENTIFICAÇÃO DE PONTOS CRÍTICOS DA PRODUÇÃO Espinosa, Caroline Stagi - Bacharel em Têxtil e Moda - Escola de Artes, Ciências e Humanidades - Universidade de São

Leia mais

Conceitos de Processos & BPM

Conceitos de Processos & BPM http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte I Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte

Leia mais

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS Cilene Loisa Assmann (UNISC) cilenea@unisc.br Este estudo de caso tem como objetivo trazer a experiência de implantaçã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

ADMINISTRAÇÃO GERAL GESTÃO DE PROCESSOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROCESSOS ADMINISTRAÇÃO GERAL GESTÃO DE PROCESSOS Atualizado em 21/12/2015 GESTÃO DE PROCESSOS Um processo é um conjunto ou sequência de atividades interligadas, com começo, meio e fim. Por meio de processos, a

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

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

GESTÃO E OTIMIZAÇÃO DE PROCESSOS. Vanice Ferreira

GESTÃO E OTIMIZAÇÃO DE PROCESSOS. Vanice Ferreira GESTÃO E OTIMIZAÇÃO DE PROCESSOS Vanice Ferreira 12 de junho de 2012 GESTÃO E OTIMIZAÇÃO DE PROCESSOS: conceitos iniciais DE QUE PROCESSOS ESTAMOS FALANDO? GESTÃO E OTIMIZAÇÃO DE PROCESSOS: conceitos iniciais

Leia mais

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

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

Leia mais

Business Process Management [BPM] Get Control. Empower People.

Business Process Management [BPM] Get Control. Empower People. Business Process Management [BPM] Get Control. Empower People. O SoftExpert BPM Suite é uma suíte abrangente de módulos e componentes perfeitamente integrados, projetados para gerenciar todo o ciclo de

Leia mais

José Benedito Lopes Junior ¹, Marcello Erick Bonfim 2

José Benedito Lopes Junior ¹, Marcello Erick Bonfim 2 ISBN 978-85-61091-05-7 Encontro Internacional de Produção Científica Cesumar 27 a 30 de outubro de 2009 Definição de uma tecnologia de implementação e do repositório de dados para a criação da ferramenta

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

BPM. (Business Process Management) Gerenciamento de Processos de Negócio. Meta IT Mapeamento de Processos BPM ARIS Módulo 1

BPM. (Business Process Management) Gerenciamento de Processos de Negócio. Meta IT Mapeamento de Processos BPM ARIS Módulo 1 BPM (Business Process Management) Gerenciamento de Processos de Negócio Meta IT Mapeamento de Processos BPM ARIS Módulo 1 Agenda 1 2 3 Conceitos BPM x TI Softwares BPM 4 Certificações Conceitos O que são

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA)

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Apresentação O programa de Pós-graduação Lato Sensu em Engenharia de Software Orientada a Serviços

Leia mais

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

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

Leia mais

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

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

Leia mais

Gestão de Processos de Negócios

Gestão de Processos de Negócios Gestão Operacional da TI Gestão de Processos de Negócios Business Process Management (BPM) Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Professor NOME: RÔMULO CÉSAR DIAS DE ANDRADE

Leia mais

GERÊNCIA DE INTEGRAÇÃO DO PROJETO

GERÊNCIA DE INTEGRAÇÃO DO PROJETO GERÊNCIA DE INTEGRAÇÃO DO PROJETO Estevanir Sausen¹, Patricia Mozzaquatro² ¹Acadêmico do Curso de Ciência da Computação ²Professor(a) do Curso de Ciência da Computação Universidade de Cruz Alta (UNICRUZ)

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

GERENCIAMENTO DE PROCESSOS DE NEGÓCIO. Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br

GERENCIAMENTO DE PROCESSOS DE NEGÓCIO. Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br GERENCIAMENTO DE PROCESSOS DE NEGÓCIO Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Guia de Estudo Vamos utilizar para a nossa disciplina de Modelagem de Processos com BPM o guia

Leia mais

Levantamento de Requisitos.

Levantamento de Requisitos. FACULDADES INTEGRADAS MATO-GROSSENSES DE CIÊNCIAS SOCIAIS E HUMANAS RESUMO Levantamento de Requisitos. Leandro Cícero da Silva Mello. Prof. Jeanine Ferrazza Meyer Metodologia e Técnica de Pesquisa- Levantamento

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

Treinamento BPMS Activiti + Elementos de NFR e Contexto. Bruno Figueiredo

Treinamento BPMS Activiti + Elementos de NFR e Contexto. Bruno Figueiredo Treinamento BPMS Activiti + Elementos de NFR e Contexto Bruno Figueiredo BPM BPM Business Process Modeling BPM Business Process Management Busca maximizar a eficiência e a efetividade do negócio, utilizando

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Pesquisa sobre Iniciativas em BPM

Pesquisa sobre Iniciativas em BPM Pesquisa sobre Iniciativas em BPM Apresentação...2 1. Perfil dos Participantes da Pesquisa...3 2. Como as organizações estão adotando o BPM... 4 2.1. Como as organizações entendem o conceito de BPM?...

Leia mais

Módulo 4: Gerenciamento de Dados

Módulo 4: Gerenciamento de Dados Módulo 4: Gerenciamento de Dados 1 1. CONCEITOS Os dados são um recurso organizacional decisivo que precisa ser administrado como outros importantes ativos das empresas. A maioria das organizações não

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

Etapas e Desafios. plataforma de BPM corporativa. BPMS Showcase 2014. Kelly Sganderla Consultora de Processos, CBPP Kelly.sganderla@iprocess.com.

Etapas e Desafios. plataforma de BPM corporativa. BPMS Showcase 2014. Kelly Sganderla Consultora de Processos, CBPP Kelly.sganderla@iprocess.com. BPMS Showcase 2014 Etapas e Desafios na seleção de uma plataforma de BPM corporativa Apresentado por: Kelly Sganderla Consultora de Processos, CBPP Kelly.sganderla@iprocess.com.br Apresentando a iprocess

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

Material de Apoio. Sistema de Informação Gerencial (SIG)

Material de Apoio. Sistema de Informação Gerencial (SIG) Sistema de Informação Gerencial (SIG) Material de Apoio Os Sistemas de Informação Gerencial (SIG) são sistemas ou processos que fornecem as informações necessárias para gerenciar com eficácia as organizações.

Leia mais

O Valor da TI. Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação. Conhecimento em Tecnologia da Informação

O Valor da TI. Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação O Valor da TI Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação 2010 Bridge Consulting

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

METODOLOGIA HSM Centrada nos participantes com professores com experiência executiva, materiais especialmente desenvolvidos e infraestrutura tecnológica privilegiada. O conteúdo exclusivo dos especialistas

Leia mais

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

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

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

Leia mais

Business Process Management [BPM] Get Control. Empower People.

Business Process Management [BPM] Get Control. Empower People. Business Process Management [BPM] Get Control. Empower People. O SoftExpert BPM Suite é uma suíte abrangente de módulos e componentes perfeitamente integrados, projetados para gerenciar todo o ciclo de

Leia mais

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN Business Process Modeling Notation Business Process Modeling Notation Página 1 Objetivo O objetivo deste curso é apresentar os elementos da notação de modelagem de processos de negócio BPMN 1.1 (Business

Leia mais

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

Leia mais

O desafio de uma visão mais ampla

O desafio de uma visão mais ampla com SAP NetWeaver BPM Descrição de Solução A competição acirrada tem levado as organizações a adotar novas disciplinas de gestão e empregar recursos tecnológicos avançados, a fim de atingir melhores índices

Leia mais

Capítulo 1 - Introdução 14

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

Leia mais

Planejamento Estratégico de TI. Prof.: Fernando Ascani

Planejamento Estratégico de TI. Prof.: Fernando Ascani Planejamento Estratégico de TI Prof.: Fernando Ascani BI Business Intelligence A inteligência Empresarial, ou Business Intelligence, é um termo do Gartner Group. O conceito surgiu na década de 80 e descreve

Leia mais

A gestão de processos de negócio: conceitos e ferramentas BPM

A gestão de processos de negócio: conceitos e ferramentas BPM FACULDADE DE LETRAS DA UNIVERSIDADE DO PORTO A gestão de processos de negócio: conceitos e ferramentas BPM Trabalho realizado por: Ana Luisa Veiga Filipa Ramalho Doutora Maria Manuela Pinto GSI 2007 AGENDA:

Leia mais

Análise de Negócios & da Informação Alexandra Hütner M.Sc. Engineer

Análise de Negócios & da Informação Alexandra Hütner M.Sc. Engineer Análise de Negócios & da Informação Alexandra Hütner M.Sc. Engineer 1 O QUE REALMENTE MUDOU??? 2 1 O Que Realmente MUDOU??? Você S/A Agosto/2011 O Que Realmente MUDOU??? Você S/A Agosto/2011 2 CENÁRIO

Leia mais

Engenharia de Requisitos- como Previnir e Reduzir Riscos

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

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS

CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS METODOLOGIA DE AUDITORIA PARA AVALIAÇÃO DE CONTROLES E CUMPRIMENTO DE PROCESSOS DE TI NARDON, NASI AUDITORES E CONSULTORES CobiT

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE Extraído do Livro "Gerenciamento de Programas e Projetos nas Organizações" 4ª Edição (a ser lançada) Autor: Darci Prado Editora INDG-Tecs - 1999-2006

Leia mais

Um processo para construção de software mais transparente

Um processo para construção de software mais transparente Um processo para construção de software mais transparente Eduardo Almentero 1, and Julio Cesar Sampaio do Prado Leite 1 1 Pontifícia Universidade Católica do Rio de Janeiro, PUC - Rio, Brasil {ealmentero,

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

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

Modelagem de Processos para Automação

Modelagem de Processos para Automação Treinamentos em Gestão por Processos Modelagem de Processos para Automação [ipe03] Implementando a Visão Futura: um curso prático para vencer a barreira existente entre negócio e TI. Implantar processos

Leia mais

BPM X Workflow. Business Process Management BPM ou Modelagem de Processos de negócio

BPM X Workflow. Business Process Management BPM ou Modelagem de Processos de negócio Business Process Management BPM ou Modelagem de Processos de negócio Metodologia Conjunto de práticas Controle, gerenciamento e integração dos processos Permite a análise, definição, execução, monitoramento

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

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 1 INTRODUÇÃO A Business Process Modeling Notation (BPMN), ou Notação de Modelagem de Processos de Negócio, é um conjunto de

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO

Leia mais

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

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

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

Wesley Vaz, MSc., CISA

Wesley Vaz, MSc., CISA Wesley Vaz, MSc., CISA Objetivos Ao final da palestra, os participantes deverão ser capazes de: Identificar e compreender os princípios do Cobit 5; Identificar e conhecer as características dos elementos

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO Departamento: Disciplina: Pré-Requisitos: I D E N T I F I C A Ç Ã O Sistemas de Informação Engenharia de Software Aplicada (ESA) Engenharia de Software (ES) CH: 7 Curso: Bacharelado em Sistemas de Informação

Leia mais

MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1

MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1 MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1 Prof. Dr. Jorge Henrique Cabral Fernandes (jhcf@cic.unb.br) Departamento de Ciência da Computação

Leia mais

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

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

Leia mais

Engenharia de Software

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

Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI

Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI Janeiro de 2011 p2 Usuários comerciais e organizações precisam

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

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES Trabalho de Graduação Orientando: Vinicius Stein Dani vsdani@inf.ufsm.br Orientadora: Giliane

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

Unidade II GESTÃO DO CONHECIMENTO. Profa. Leonor Cordeiro Brandão

Unidade II GESTÃO DO CONHECIMENTO. Profa. Leonor Cordeiro Brandão Unidade II GESTÃO DO CONHECIMENTO Profa. Leonor Cordeiro Brandão Relembrando Vimos alguns conceitos importantes: O que são dados; O que é informação; Quando uma informação se transforma em conhecimento;

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

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 QUALIDADE DE SOFTWARE Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 Objetivos Apresentar o processo de gerenciamento de qualidade e as atividades centrais da garantia de

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 03 Profissões de TI Prof. MSc. Edilberto Silva edilms@yahoo.com http:// Papéis... Um papel é uma definição abstrata de um conjunto de atividades executadas e dos respectivos

Leia mais

Disciplina: Automação de Processos de Negócio

Disciplina: Automação de Processos de Negócio Disciplina: Automação de Processos de Negócio PÓS-GRADUAÇÃO EM GESTÃO ESTRATÉGICA DE PROCESSOS DE NEGÓCIO Professor: Eros Viggiano Ementa da disciplina Viabilização da otimização de processo através da

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 3. Gerência de

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais