UMA SOLUÇÃO ORIENTADA A PROCESSOS PARA AUXILIAR A IMPLANTAÇÃO DO NIVEL G DO MPS.BR

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

Download "UMA SOLUÇÃO ORIENTADA A PROCESSOS PARA AUXILIAR A IMPLANTAÇÃO DO NIVEL G DO MPS.BR"

Transcrição

1 1 Universidade de Pernambuco Faculdade de Ciência e Tecnologia de Caruaru Bacharelado em Sistemas de Informação UMA SOLUÇÃO ORIENTADA A PROCESSOS PARA AUXILIAR A IMPLANTAÇÃO DO NIVEL G DO MPS.BR Trabalho de Graduação Sistemas de Informação Ana Letícia Ferreira da Costa Orientador: Prof. Msc. Rômulo César Dias de Andrade

2 2 ANA LETÍCIA FERREIRA DA COSTA UMA SOLUÇÃO ORIENTADA A PROCESSOS PARA AUXILIAR A IMPLANTAÇÃO DO NÍVEL G DO MPS.BR Monografia apresentada como requisito parcial para obtenção do diploma de Bacharel em Sistemas de Informação pela Faculdade de Ciência e Tecnologia de Caruaru Universidade de Pernambuco. Caruaru, dezembro, 2014

3 3 Dedico este trabalho aos meus pais, Otávio José (in memoriam) e Amparo, pela motivação aos estudos, amor e ensinamentos.

4 4 Agradecimentos A Deus, por me dar perseverança, força, auxílio e fé para que esse trabalho pudesse ser concluído. A minha mãe, Amparo, por ser um verdadeiro amparo em minha vida, me orientando e incentivando nos momentos de aflição. Ao meu pai, Otávio José (in memoriam), que embora não esteja fisicamente comigo, seus ensinamentos prevalecerão para sempre em minha vida. As minhas avós, Valdeci (in memoriam), com seu modo simples de enxergar o mundo, Marlene (in memoriam), que viu em mim aptidão para com os estudos e a minha bisavó Rosa, com seu modo peculiar de apreciar o conhecimento. A toda minha família pelo apoio incondicional, em especial aos tios: Zé Carlos, por ser um exemplo de perseverança em relação aos estudos, Hozana, por sempre ver o lado bom das coisas e Jô, que, por tantas vezes me acolheu em sua casa. Ao meu namorado, Felipe, pela compreensão durante todos os momentos necessários para elaboração deste trabalho. Aos meus vizinhos, que indiretamente me forneceram internet. Aos professores, que contribuíram com minha formação acadêmica, em particular ao meu orientador, Rômulo César, pelo incentivo e força nos momentos de fraquejo. Aos meus amigos pelo apoio dado durante toda a graduação, de modo notável, Polly, Karine e Élida, que mostraram que uma amizade verdadeira pode surgir independentemente de onde se esteja. E a todos, que de uma forma ou de outra contribuíram para que este trabalho acontecesse.

5 5 Resumo Atualmente o cenário de competição e profissionalismo obriga organizações a buscarem efetividades nos seus processos de desenvolvimento de software como uma forma de aumentar a qualidade dos serviços prestados. É essencial que as etapas do desenvolvimento de software bem como as fases de levantamento dos requisitos estejam claras e definidas, garantido conformidade para empresas e clientes e assim reduzindo os custos com retrabalho e falta de entendimento devido a requisitos de sistemas que foram mal relatados. A demanda por desenvolvimento de softwares é inevitável, ocasionando requisitos de implementação cada vez mais complexos, onde as fábricas de softwares utilizam modelos de referências para guiar os seus processos. As empresas vêm melhorando os seus procedimentos de especificação de requisitos, tendo em vista que as adoções de boas práticas trazem resultados significativos para as mesmas. Diante desse cenário de processo e especificação de requisitos, este trabalho apresenta um estudo sobre automação de processos com ênfase em BPMS (Busines Process Management System) juntamente com a especificação de requisitos com ênfase no Nível G do MPS.BR (Melhoria do Processo de Software Brasileiro). A finalidade do trabalho proposto é de gerenciar a especificação de requisitos, controlando e dando visibilidade de todas as etapas do processo e com isso melhorando a comunicação entre empresas e clientes evitando assim interpretações erradas destes requisitos e garantido as entregas nos prazos corretos, tendo em vista que a ferramenta proposta controla os tempos em cada fase e assim gera relatórios gerencias para as partes interessadas. Em virtude do uso de um processo definido previamente, será possível identificar possíveis gargalos e trabalhar de forma efetiva para corrigir eventuais problemas que possam existir na fase de especificação de requisitos. Palavras-chave: Qualidade de Software; Requisitos; BPMS; MPS.BR Nível G; Processo;

6 6 Abstract Currently the competition scenario and professionalism requires organizations to seek effectivities in their software development processes as a way to increase the quality of services provided. It is essential that the stages of software development and the lifting phase of the requirements are clear and definite, guaranteed compliance for businesses and consumers and thereby reducing the cost of rework and lack of understanding due to system requirements that were poorly reported. The demand for development of software is inevitable, causing implementation requirements increasingly complex, where the software factories use reference models to guide their processes. Companies have improved their requirements specification procedures, given that the adoption of best practices bring significant results for the same. Given this scenario process and requirements specification, this paper presents a study on process automation with emphasis on BPMS (Busines Process Management System) together with the specification requirements with emphasis on Level G of MPS.BR (Improving the Software Process Brazilian). The purpose of the proposed work is to manage the requirements specification, thus controlling and giving visibility of all stages of the process and thereby improving communication between businesses and customers avoiding misinterpretation of these requirements and guaranteed deliveries at the right time, with a view that the proposed tool controls the times when each phase and thus generates management reports for stakeholders. Due to the use of a process defined previously, you can identify potential bottlenecks and work effectively to address any problems that may exist in the requirements specification phase. Keywords: Software Quality; Requirements; BPMS; MPS.BR Level G; Process;

7 7 INDICE DE FIGURAS Figura 1 - Estrutura do Modelo de Prototipação Figura 2 - Correspondência entre o CMMI e o MPS.BR Figura 3 - Áreas de Conhecimento em BPM Figura 4 - Fases da Modelagem, adaptado Figura 5 - Interface Principal do BizAgi Studio Figura 6 - BizAgi Studio, Aba do Model Process Figura Fase em que um Processo se Encontra Figura Fases da Modelagem, Etapa de Elicitação dos Requisito Figura 9 - Modelagem de Dados na Ferramenta Figura 10 - Implementação da Fachada Figura 11 - Regra de Negócios Figura 12 - Separação dos Grupos de Requisitos Figura 13 - Tela de login Figura 14 - Tela de Afazeres Figura 15 - Gráfico para Acompanhamento de Projetos Figura Criação e Definição do Papel de Analista Figura 17 - Trabalhos em Andamento por Usuário Figura 18 - Resumo do Tempo de Ciclo... 55

8 8 INDICE DE TABELA Tabela 1 - Fases da Ferramenta... 46

9 9 LISTA DE SIGLAS ABPMP ASD BPM BPMN BPMS CMM CMMI CBoK DSDM ISO MCT MPS MPS.BR MR-MPS PMBOK Sepin SEI SWEBoK SW-CMM TI UML Association of Business Process Management Professionals Adaptive Software Development Business Process Management Business Process Model and Notation Business Process Management Suite Capability Maturity Model Capability Maturity Model Integration Guia para o Gerenciamento de Processos de Negócios Dynamic Systems Development Methodology International Organization for Standardization Ministério da Ciência e Tecnologia Melhoria do Processo de Software Melhoria do Processo de Software Brasileiro Modelo de Referência do MPS.BR Project Management Body of Knowledge Secretaria de Política de Informática Software Engineering Institute Software Engineering Body of Knowledge Software Capability Maturity Model Tecnologia da Informação Linguagem de Modelagem Unificada

10 10 SUMÁRIO 1 INTRODUÇÃO CARACTERIZAÇÃO DO PROBLEMA OBJETIVOS JUSTIFICATIVA METODOLOGIA DA PESQUISA ORGANIZAÇÃO DO TRABALHO REFERENCIAL TEÓRICO ENGENHARIA DE SOFTWARE Prototipagem de Software MODELAGEM DE SOFTWARE Engenharia de Requisitos GESTÃO DE QUALIDADE Qualidade de Software Melhoria do Processo de Software Brasileiro (MPS.BR) Nível G de Qualidade GERENCIAMENTO DE PROCESSOS DE NEGÓCIOS (BPM) Tecnologia da Informação Aplicada à Gestão por Processos (BPMS) CONSIDERAÇÕES FINAIS RESULTADOS E DISCUSSÕES CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS... 57

11 11 1 INTRODUÇÃO A invenção dos computadores foi algo que revolucionou a humanidade, pois, a partir do surgimento e evolução destes objetos, Filho (2013), pessoas passaram a depender cada vez mais da comodidade oferecida por estes. Para tanto, é necessário que os softwares desenvolvidos atendam sempre aquilo que o usuário final anseie. É neste cenário que se destaca a engenharia de software e todas as facilidades oferecidas por esta área tão promissora Filho (2013). Portanto, para que o produto de software desenvolvido tenha qualidade, seja entregue no prazo definido, tenha um custo razoável e ainda atenda às necessidades dos usuários é essencial que possua qualidade em seu desenvolvimento já que estes fatores influenciam de forma direta o produto produzido e proporcionam destaque junto ao mercado competitivo, Anjos e Moura (2014). O que não se deve esquecer é que, softwares caóticos e ineficientes levam organizações desenvolvedoras a perderem mercado, Filho (2013). Motivar organizações às práticas proporcionadas pela qualidade é um desafio constante já que muitas das organizações deixam esta prática como segundo plano; investir em qualidade é algo que só traz benefícios, uma vez que serão observados os produtos de softwares desenvolvidos assim como o grau de maturidade em que a empresa se encontra com a finalidade de obter certificação de qualidade, Gomes (2000). Presentemente existem alguns órgãos responsáveis por ditar as normas de qualidade que um produto de software deve ter; tanto internacionais, CMMI (Capability Maturity Model Integration), ISO (International Organization for Standardization) e suas normas, bem como nacional, MPS.BR (Melhoria do Processo de Software Brasileiro). Uma vez que softwares são desenvolvidos, estes necessitam de uma equipe de gerenciamento e desenvolvimento; tais equipes precisam estar cientes do grau de produtividade em que o projeto se encontra. Fazer uso de gerenciamento de processos de negócios (BPM) no desenvolvimento de softwares é algo muito útil e quando agregado as práticas de qualidade transformam-se em algo extraordinariamente proveitoso. Utilizar BPM em um processo de software possibilita a transformação deste processo, BPM, CBOK (2013), pois é possível representa-lo graficamente bem como automatiza-lo, não esquecendo de que também é possível fazer o gerenciamento destes processos em desenvolvimento.

12 12 Antes de se pensar que é impossível fazer esta integração entre dois processos distintos, sendo um voltado a qualidade e o outro à automação, lembremo-nos das oportunidades oferecidas pelo Busines Process Management System (BPMS), como forma de automatizar a gestão de processos de negócios. Sendo assim, este projeto busca criar uma solução orientada a processos com o uso de BPMS, o mesmo toma como ênfase o modelo de melhoria e avaliação do processo de software MPS.BR nível G para que micro, pequenas e médias empresas possam adotar esta ferramenta como metodologia de trabalho. 1.1 CARACTERIZAÇÃO DO PROBLEMA Entende-se por engenharia de software o estabelecimento e uso de sólidos princípios que integra métodos, ferramentas e procedimentos para o desenvolvimento de softwares. Quanto à qualidade são todos os artefatos produzidos durante seu desenvolvimento, ou seja, modelos, documentos, relatórios, código fonte, código executável, cronograma, etc., estes, tem que satisfazer as necessidades dos clientes, colaboradores, acionistas e usuários finais. Uma pesquisa realizada com organizações nacionais mostrou que 43% dos processos de software foram cancelados ou entregues com falhas comprometedoras no produto (ATALLA apud RIBEIRO, et, al., 2011). Segundo Furtado, certos tipos de falhas que ocorrem em projetos de software são ocasionados quando o cliente, ou usuário final é ignorado, pois, a falta de envolvimento desta parte, durante todo o desenvolvimento do projeto, está diretamente relacionada ao fracasso. Analisando tal cenário, em 2003 a Associação para Promoção da excelência do Software Brasileiro (SOFTEX), que conta com o apoio de diversas empresas e ministérios criou o MPS.BR (Melhoria de Processos do Software Brasileiro), este programa, busca atender as necessidades do mercado e, ao mesmo tempo, manter os padrões de qualidade exigidos por órgãos competentes, o MPS.BR subdivide-se em 7 níveis, que vão do G (sendo este, o nível mínimo de qualificação) ao A (sendo este, o nível máximo de qualificação). Sabe-se, que o mercado de Tecnologia da Informação (TI), está cada vez mais crescente e cada vez mais quebrando barreiras geográficas; é nesse cenário que, em Pernambuco, destaca-se um grande polo de desenvolvimento e soluções inovadoras, o Porto

13 13 Digital, que age como uma incubadora de empresas, onde, para se desenvolver softwares, é essencial que se tenha certificação nível G. É diante desse cenário que surge a seguinte problemática: Como utilizar processos automatizados para auxiliar na implantação do MPS.BR nível G? De acordo com Sommerville (2011), um software além de corresponder às expectativas do usuário, precisa ser confiável; e para ser confiável, precisa seguir padrões de qualidade, tais padrões são ditados pelo MPS.BR, que segue modelos e normas internacionais a fim de que a indústria de software nacional atenda cada vez mais as necessidades dos seus clientes. 1.2 OBJETIVOS Este trabalho tem como objetivo geral propor uma solução automatizada que guie as empresas a partir dos processos Nível G do MPS.BR na implantação deste programa. E como objetivos específicos: o Compreender os processos do MPS.BR Nível G e relacionar suas boas práticas com BPM. o Definir um modelo de implantação do MPS.BR nível G orientada a processos através de um BPMS(Tecnologia da Informação Aplicada a Gestão de Processos) o Estimar o tempo para as atividades de implantação. o Criar papéis e fases de implantação. o Definir fluxos de trabalho. 1.3 JUSTIFICATIVA Como já é costume, a maior parte de micro, pequenas e médias empresas utilizam metodologias tradicionais para realizarem suas tarefas, porém nem sempre utiliza-las surte o efeito esperado, Magalhães e Pinheiro (2007).

14 14 A pratica de Business Process Model and Notation (BPMN) contribui para um ambiente de trabalho mais dinâmico, além de proporcionar maior comodidade quanto às atividades de execução de estratégia de negócios que estas empresas estabelecem. Já as normas de qualidade MPS.BR servem para atribuir métricas a fim de que estas empresas possuam certificação de qualidade, SOFTEX (2013). Sendo assim, este trabalho visa integrar estas duas ferramentas, sendo uma voltada a processos, BPMN, que tem como intuito gerir um conjunto de boas práticas no processo de negócios e a outras voltada a qualidade, MPS.BR, como forma de melhorar gradativamente o processo de software destas empresas, para tanto daremos ênfase ao Nível G de qualidade por ser este o nível mínimo de qualificação que uma empresa deve ter. A proposta de implantação do Nível G do MPS.BR através de uma ferramenta orientada a processos, para micro, pequenas e médias empresas sobressai-se por ser dinâmica, ágil e intuitiva assim como é proposto pelo BPMN. Porém, de acordo com Magalhães e Pinheiro (2007) mudar a cultura organizacional de empresas é uma tarefa árdua, mesmo que o objetivo seja aumentar a produção e a qualidade dos produtos e serviços pois os gestores estão acostumados com o modelo já existente. Mesclar diferentes ferramentas pode contribuir para que a empresa tenha mais controle acerca dos artefatos de software produzidos, já que a ferramenta proposta facilita o modo como os gestores administram os projetos. A ferramenta desenvolvida propõe às empresas automação dos seus processos para que a partir disto o tempo de desenvolvimento de cada fase de um projeto de software possa ser acompanhado assim como cada pessoa responsável por uma fase, ou seja, a ferramenta indica a definição do fluxo dos trabalhos correntes na empresa. 1.4 METODOLOGIA DA PESQUISA Entende-se por metodologia, um conjunto de regras e métodos, ou seja, procedimentos organizados que conduzem a certo resultado. De acordo com Cervo, Bervian e Da Silva (2006), nos estudos científicos, os métodos são conjuntos de processos utilizados para investigar a demonstração da verdade. Sendo assim, como forma de validar esta pesquisa, algumas etapas consideradas cruciais foram abordadas.

15 15 A presente pesquisa caracteriza-se por ser exploratória, pois, segundo Cervo, Bervian e Da Silva (2006), este tipo de pesquisa realiza descrições precisas e quer descobrir as relações existentes entre seus elementos componentes. Para tanto será desenvolvida uma ferramenta orientada a processos; esta auxiliará a implantação do nível G em empresas desenvolvedoras de software, seguindo as normas estabelecidas pelo MPS.BR. Ainda de acordo com Cervo, Bervian e Da Silva (2006) qualquer espécie de pesquisa e em qualquer área de estudo, é primórdio que seja feita uma pesquisa bibliográfica; seguindo este pensamento, um estudo bibliográfico detalhado sobre engenharia e modelagem de software, gestão de qualidade com base no MPS.BR nível G e Busines Process Management Suite (BPMS) foi realizado, tendo como objetivo criar embasamento teórico para esta pesquisa. Para que pudesse ser feito o acompanhamento do desenvolvimento da ferramenta, foi adotado o modelo de prototipagem de software, este, gera versões parciais e preliminares de um sistema de software que esteja sendo desenvolvido, Souza (2014), como este trabalho tem por objetivo desenvolver uma ferramenta de software orientada a processos, este modelo de desenvolvimento enquadrou-se de forma satisfatória ao desenvolvimento desta ferramenta, uma maior explanação acerca do assunto será exibido no capítulo 2. Ao ser efetivada a revisão da literatura, descrita no capítulo 2 observou-se a importância de conectar gerenciamento de processos à qualidade de software, tendo em vista viabilizar o desenvolvimento de softwares realizado por micro, pequenas e médias empresas. Para finalizar foi realizada uma pesquisa qualitativa, que, de acordo com Otani e Fialho (2011), são levados em conta a relação diligente entre objetividade e subjetividade o qual não pode ser traduzido em números; para Flick (2009) este tipo de pesquisa consiste na relevância e análise de diferentes perspectivas para o pesquisador, já que são levadas em conta variedade das abordagens bem como os métodos reflexivos no que diz respeito ao processo de produção do conhecimento. Uma pesquisa qualitativa não requer o uso de métodos e técnicas estatísticas (OTANI, FIALHO, 2011, p. 38) já que, ainda de acordo com Otani e Fialho (2011) os dados necessários para realização da coleta estão disponíveis no meio natural, e, o pesquisador é o instrumento-chave para coleta-las. Pesquisas do tipo qualitativas tendem a ser descritivas, pois o pesquisador tende a analisar os dados indutivamente, e o processo e seu significado são os focos principais da abordagem. (OTANI, FIALHO, 2011, p. 38).

16 ORGANIZAÇÃO DO TRABALHO O conteúdo deste trabalho está estruturado em cinco capítulos: o No capítulo 1 foi feita uma breve introdução acerca dos principais motivos que levaram a realização deste trabalho, seus objetivos e metodologia utilizada; o No capítulo 2 foi feita a revisão da literatura que aborda assuntos como engenharia de software e o modelo de prototipagem de desenvolvimento, modelagem e gestão da qualidade de software e para finalizar, foi tratado do tema BPM; o Capítulo 3 apresenta os resultados, assim como as discussões acerca do estudo realizado; o E para finalizar, o capítulo 4 aborda as conclusões deste trabalho. 2 REFERENCIAL TEÓRICO Como forma de embasar a pesquisa aqui apresentada, foi-se analisado o estudo da arte referente à engenharia de software. O presente referencial teórico traz como peças chave, a modelagem de software, que de acordo com Pfleeger (2004), modelar softwares é analisar os procedimentos necessários para que ações possam ser acompanhadas e tomadas de forma correta; gestão da qualidade de software, que, segundo Pressman (2011) é o processo onde se verifica os requisitos existentes no projeto, bem como o grau de satisfação do cliente; MPS.BR com ênfase no nível G de qualidade, de acordo com o guia de implementação desenvolvido pela SOFTEX tal programa busca atender as necessidades do mercado ao mesmo tempo que mantém os padrões de qualidade exigidos por órgãos competentes; BPM, para Barrios(2012), BPM nada mais é que o conhecimento dos processos executados a fim de gerencia-los, para, daí realizar melhorias e evoluir tais processos; BPMS, a empresa MasterHause, especializada em consultorias e treinamentos nos diz que o BPMS é um conjunto de funções que tem por objetivo modelar processos de negócios de maneira padronizada.

17 ENGENHARIA DE SOFTWARE Assim como aconteceu à humanidade, com o software não foi diferente; ambos sofreram intensas evoluções, cada uma ao seu tempo e com sua importância. O software passou a fazer parte da vida das pessoas de tal forma que não conseguimos imaginar o mundo sem as facilidades oferecidas a nós por eles. Mas nem sempre foi assim, segundo Wirth (2012), no princípio havia muitas limitações e por isso a ênfase no hardware era substancial; ainda de acordo com este autor, os anos 50 foram marcados pelo desenvolvimento de diversas linguagens de programação baixo nível; foi apenas nos 60, quando os computadores ganharam características multiprogramação que houve a popularização destes, porém, tal popularização trouxe consigo a necessidade de se desenvolver programas e aplicativos cada vez mais robustos; para tanto, era necessária a contínua evolução do hardware agregada à experiência dos programadores, na prática, as coisas não funcionavam desta forma, as melhorias no hardware, prometidas pelas grandes empresas que fabricavam os computadores não eram cumpridas, nem tão pouco, os programadores eram dotados de experiência nesta nova área. Em 1968, uma conferência patrocinada pela NATO, foi dedicada ao tema (1968 em Garmisch-Partenkirchen, Alemanha). Apesar de críticas terem ocasionalmente sido expressas anteriormente, só após a conferência as dificuldades foram discutidas abertamente e confessadas com franqueza incomum, e os termos Engenharia de Software e Crise de Software foram criados. (Niklaus, 2012). De acordo com Pressman (2011), atualmente o software assume duplo papel e estes papeis sofreram mudanças expressivas ao longo dos últimos cinquenta anos. Algumas dessas mudanças foram, Aperfeiçoamento significativo no desempenho do hardware, mudanças profundas nas arquiteturas computacionais, vasto aumento na capacidade de memória e armazenamento, e uma ampla variedade de exóticas opções de entrada e saída, tudo isso resultou em sistemas computacionais mais sofisticados e complexos. (Pressman, 2011, p.31).

18 18 Para Falbo (2005) desenvolver softwares não deve ser confundido com programar softwares. Estas são duas realidades diferentes; ao tratarmos do termo desenvolver softwares, visamos melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento, através de métodos, técnicas, ferramentas, dentre outros (FALBO, 2005, Introdução), a este conjunto de métodos atribuímos o nome de engenharia de software. Para França (2012), programar softwares é escrever códigos a partir de uma linguagem de programação existente, revisar e realizar testes de modo que haja uma interação entre o hardware, o sistema operacional e o usuário final. Ambos os processos são estritamente parecidos, porém, para Sommerville (2011) a engenharia de software foca todas as metodologias de desenvolvimento, desde o estágio inicial, onde são obtidas as especificações necessárias do sistema até sua manutenção, ou seja, quando o sistema desenvolvido já está sendo usado. No geral, os softwares passam por algumas etapas durante seu desenvolvimento, a esta cadeia dá-se o nome de processo de software, pode-se dizer que algumas atividades são comuns a todos os projetos, por exemplo: elicitação dos requisitos, onde os clientes e engenheiros se reúnem a fim de definir o software a ser produzido, bem como suas restrições; desenvolvimento do software, ou seja, fase onde os requisitos definidos são programados e é feita uma projeção; validação do software, nesta etapa, é feita uma análise do software produzido, para garantir que o mesmo está de acordo com as especificações do cliente; evolução do software, isto acontece quando há necessidade de modificação, ou seja, quando há uma atualização da versão do software produzido. O modelo de ciclo de vida é a primeira escolha a ser feita no processo de software. A partir desta escolha definir-se-á desde a maneira mais adequada de obter as necessidades do cliente, até quando e como o cliente receberá sua primeira versão operacional do sistema. (DevMedia 36, 2012, p.1). Pode-se dizer que os modelos de ciclo de vida funcionam como a estrutura onde serão ajustadas as fases do projeto para que assim, este vá tomando forma; outro ponto de notoriedade nesta etapa é a detecção de erros; pois bem, o erro, quanto mais cedo for descoberto, mais vantajoso o é, pois assim evita-se o retrabalho, além de que contribui para a qualidade do software, o cumprimento dos prazos, bem como todos os custos associados.

19 19 Para o professor Prado (2014), É essencial, antes do desenvolvimento de um produto, preparar um plano geral, ou seja, escolher um modelo de ciclo de vida. (PRADO, 2014, p.1). De acordo com a revista DevMédia (2014), não existe um modelo de ciclo de vida específico para cada projeto, a escolha de um ou mais modelos vai depender da complexidade do negócio do cliente, bem como nível de confiabilidade, ambiente operacional, custos, equipe de desenvolvimento, dentre outros fatores. Para que haja acompanhamento dos desenvolvedores e da empresa contratante e uma documentação atualizada para assim haver validação de cada uma das etapas, os projetos fazem uso de modelos de software, alguns desses modelos são: o Modelo Cascata: Este modelo tem como finalidade de estabelecer ordem no desenvolvimento de grandes produtos de software. (RAMOS, CARLOS, LEITÃO, COSTA, 2010, Introdução); recebe este nome, pois obedece a uma ordem de classes, aqui, cada fase só inicia quando a anterior termina e a nova fase iniciada recebe os atributos da classe anterior. o Modelo em V: Este modelo introduz a criação de testes de dados e cenários de teste durante o ciclo de desenvolvimento do software, e trabalha com diferentes níveis de testes como: unidade, integração, sistema e aceitação. (MACORATTI, 2008, p. 1). o Modelo Incremental: Batista e Santos (2012) afirmam que o modelo incremental foi sugerido por Barry Boehm, e que seu desenvolvimento é dividido em etapas, e estas etapas são incrementadas até sua versão final, daí o nome modelo incremental. Neste tipo de modelo, o cliente acompanha diretamente cada fase de desenvolvimento do projeto, além de poder opinar se tudo está saindo como o esperado. o Modelo Evolutivo: Este tipo de modelo tem como desígnio apresentar características que possibilitem desenvolver versões cada vez mais complexas do software. (PRESSMAN, 2011, p. 62). o Modelo Espiral: De acordo com Pressman (2011), o modelo espiral foi proposto por Barry Boehm, e tal modelo funciona como uma junção dos modelos cascata, prototipação e também o modelo interativo. o Rational Unifield Process (RUP): O RUP é um processo bem estruturado para que o desenvolvimento de softwares seja uma tarefa previsível e repetível possui alta qualidade além de levar em conta a acuidade da comunicação com

20 20 os clientes, é iterativo e incremental, proporcionando a sensação evolucionária que é essencial no desenvolvimento de software moderno. (PRESSMAN, 2011, p. 72) Prototipagem de Software Prototipação, é a montagem de protótipos, ela pode ser classificada de acordo com uma variedade de dimensões. (LESSA, JUNIOR, 2009, p. 4). O que os autores quiseram dizer foi que as diferentes etapas de desenvolvimento de software, como por exemplo, levantamento dos requisitos, documentação, codificação, testes, entre outros, são considerados, porém, não necessariamente estas etapas precisam ser seguidas de modo formal. Este tipo de modelo de desenvolvimento oferece vantagens, como por exemplo: o Requisitos necessários não precisam ser totalmente declarados no início de um projeto, e, podem ainda ser editados caso haja essa necessidade. o A entrega do protótipo é feita ao cliente assim como as especificações e definições para que o usuário final saiba utilizar o software; a satisfação e entendimento destes usuários são levados em conta. Estas vantagens oferecidas servem para certificar que o ambiente de desenvolvimento destes softwares está sendo funcional, Lessa, Júnior (2009), pois, o principal objetivo da prototipagem é que a construção total ou parcial de um produto de software seja feita de forma rápida para que assim a equipe desenvolvedora bem como os usuários finais cheguem a um consenso do que realmente é necessário para a construção de um software, Pfleeger (2004). O modelo de prototipagem, tem como intuito revelar ao cliente uma versão inicial do sistema, esta primeira versão serve para testar possibilidades, ou seja, mostrar conceitos, experimentar opções do projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções. (BATISTA; SANTOS; 2012, p.1), evitando-se assim, gastos com futuras correções de erros. A figura 1 mostra a estrutura do modelo de prototipação.

21 21 Figura 1 Estrutura do Modelo de Prototipação. Fonte: Pfleeger (2004). Protótipos de software, servem para auxiliar diligências no processo de engenharia de requisitos, já que, na maioria dos projetos, a versão beta serve apenas de orientação quanto ao bom funcionamento, rapidez na execução entre outros fatores que dizem respeito à qualidade. Esta prototipação pode ser mostrada aos usuários de diversas formas, modelo executável, bem como, projeções, protótipos de papel, protótipos existentes, etc. 2.2 MODELAGEM DE SOFTWARE Modelagem abrange tanto análise quanto projeto, descrevendo representações do software que se tornam progressivamente mais detalhadas. (Pressman, 2011, p. 123). Para Castilho (2008), modelar software é algo parecido à planta de uma casa, é a representação simplificada de algo real. Tais representações servem para que haja um acompanhamento do que o projeto deverá ter e fazer, a isto dá-se o nome de fluxos de dados. Apesar de cada projeto de software ter sua particularidade, de acordo com Pressman (2011) podemos fazer uso de metodologias existentes para auxiliar o seu desenvolvimento. Pode-se dizer que o pontapé inicial de um projeto de software é levantar os requisitos para

22 22 que assim, o desenvolvimento do projeto esteja como o cliente ou usuário final almeje. De acordo com Sommerville (2011), atualmente os modelos de software são, na maioria das vezes representados por algum tipo de notação gráfica baseadas em notação UML (linguagem de modelagem unificada), porém, também é possível que tal representação seja feita por modelos matemáticos como forma de se especificar detalhes do sistema. Desse modo, este trabalho aborda as técnicas utilizadas a partir das notações UML sob uma perspectiva estrutural, já que será criada uma modelagem a fim de exemplificar os requisitos que comporão a ferramenta orientada a processos. Neste novo modelo de sistema os requisitos estarão documentados a fim de facilitar o entendimento e também, para seguir normas de qualidade ditadas pelo MPS.BR. Os modelos estruturais podem ser modelos estáticos, que mostram a estrutura do sistema, ou dinâmicos, que mostram a organização do sistema quando ele está em execução. (SOMMERVILLE, 2011, p. 89). Como será desenvolvida uma ferramenta orientada a processos, está será estruturada de modo estático e dinâmico, pois, após finalizar a modelagem, está será automatizada. Para tanto, no momento da modelagem, serão utilizados diagramas de classes para que se tornem mais claras as associações existentes entre elas; além disso, também será detalhado nessa modelagem, modelos semânticos de dados, eles mostram as entidades dos dados, seus atributos associados, e as relações entre essas entidades. (SOMMERVILLE, 2011, p. 90), funcionam como uma espécie de banco de dados, já que, os diagramas UML não os possui; muitas vezes, os dados podem ter características em comum, e, quando isto acontece, a UML dispõe de um tipo especial de associação entre as classes, conhecida por agregação de dados, aqui, um objeto é composto por um conjunto de outros objetos (Sommerville, 2011) Engenharia de Requisitos Projetar e construir softwares é desafiador, criativo e pura diversão. (PRESSMAN, 2011, p. 127). Bem, a tarefa de desenvolver softwares é sim empolgante, e, por tal motivo, muitos desenvolvedores esquecem de levantar os requisitos necessários para o sucesso do projeto.

23 23 Apesar de parecer desnecessário que haja documentação e acompanhamento do projeto que está sendo desenvolvido, erros graves podem vir a surgir caso não haja planejamento das ações que deverão ser tomadas; por tudo isso, criou-se o termo engenharia de requisitos, esta, serve como referência para as atividades de desenvolvimento e acompanhamento de projetos de software, pois, Na perspectiva do processo de software, a engenharia de requisitos é uma ação de engenharia de software importante que se inicia durante a atividade de comunicação e contínua na de modelagem. Ela deve ser adaptada às necessidades do processo, do projeto, do produto e das pessoas que estão realizando o trabalho. (Pressman, 2011, p. 127). É a partir da engenharia de requisitos que são analisadas as propostas dos clientes, que, de acordo com Pressman (2011), seguem sete tarefas distintas onde algumas ocorrem em paralelo, e ambas são utilizadas de acordo com as necessidades de cada projeto; estas tarefas são: o Concepção: Nesta fase os clientes formalizam os requisitos fundamentais, determinam as restrições primordiais dos projetos e abordam as principais características e desempenhos que devem estar presentes para que o sistema atenda às necessidades dos clientes ou usuários finais. o Levantamento: Na fase de levantamento dos requisitos é importante que sejam realizadas reuniões com a presença da equipe desenvolvedora bem como dos clientes, para que sejam definidas as necessidades bem como as funcionalidades do software desenvolvido. o Elaboração: A fase de elaboração é responsável por expandir as necessidades identificadas nas fases de concepção e levantamento, por meio de conjuntos de elementos comportamentais, orientados a fluxos e baseados em cenários e classes, este modelo, faz ainda alusões a padrões de análises, e soluções para problemas recorrentes em distintas aplicações, Presman (2011). o Negociação: Fase em que a prioridade dos requisitos bem como a disponibilidade e os custos relativos são analisados e negociados pela equipe desenvolvedora e também pelos interessados no projeto. o Especificação: Descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado. (LEITE, 2000, p.1). Após esta análise, são levantados

24 24 possíveis problemas no software que será implementado, e, soluções são mostradas para que tais problemas sejam efetuados de forma segura; tem uma visão voltada para a comunicação sistemática entre as classes, pois assim, indica quais das propriedades funcionais são mais diligentes para resolver o problema de domínio. o Validação: Como certificação que foi feito aquilo que o cliente ou usuário final deseja, esta responsabilidade recai sobre a validação dos requisitos. Além disso, esta fase também é responsável por corrigir possíveis erros no projeto como um todo, evitando que sejam necessários retrabalhos após a entrega da versão final ao cliente. o Gestão: Fase de extrema importância para a engenharia de requisitos já que nesta fase a equipe de desenvolvimento consegue controlar, identificar e acompanhar as mudanças feitas ao longo do desenvolvimento do projeto. Para o Institute of Eletricaland Eletronics Engineers (IEEE, 1990), analisar requisitos de software é uma cadeia onde são ponderadas as necessidades dos clientes, e, a partir delas são determinados o sucesso ou fracasso do projeto (QUITERIO, 2012). É primordial que os requisitos que foram levantados, sejam relevantes para o projeto, Pois, eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor sobre o que o software fará, e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal definidos implicam num retrabalho. (QUITERIO, 2012, p.1). 2.3 GESTÃO DE QUALIDADE Na engenharia de software estabelecer metas e cumprir prazos é de suma importância para que se obtenha excelência no produto produzido. Com a evolução constante deste mercado, empresas desenvolvedoras de software estão mais conscientes que nunca de que qualidade e produtividade andam juntas, e, para que haja eficiência nestas tarefas, o processo de produção de softwares deve ser eficiente. Ao pensarmos em qualidade, imaginamos algo livre de erros ou defeitos, e em excelentes condições, mas, e no ambiente organizacional?

25 25 Neste tipo de ambiente podemos encontrar diversos significados que nos submetem à qualidade; atendimento as expectativas do cliente, conformidade com a especificação, conhecimento do processo para melhora-lo, efetividade e usabilidade. (VASCONCELOS et al., 2006, p. 73). Como visto, definir qualidade não é uma tarefa fácil, já que esta pode ser vista de vários ângulos; no campo da engenharia de software este é um termo a ser tratado com delicadeza já que softwares são bens intangíveis além de que podemos estar nos referindo a qualquer etapa do processo de software, que vai desde uma visão transcendental até uma visão de mercado. Garvin (1984) comenta detalhadamente quais são as perspectivas de qualidade e o que elas significam: o o o o o Visão Transcendental: Onde a qualidade é algo que podemos reconhecer, mas não podemos definir. Visão do Usuário: Onde a qualidade é adequação ao propósito pretendido. Visão do Fabricante: Onde a qualidade é a conformidade com a especificação. Visão do Produto: Onde a qualidade está relacionada às características inerentes ao produto. Visão do Mercado: Onde a qualidade depende do valor que os consumidores estão dispostos a pagar pelo produto. (GARVIN, 1984, p ). De acordo com Pfleeger (2004), devemos considerar a qualidade de software a partir de três ângulos: o Qualidade do Produto: Esta característica deve ser analisada sob dois pontos de vista; do usuário, estes vão analisar se o software desenvolvido corresponde a suas expectativas, ou seja, se ele faz aquilo que foi projetado para fazer, o usuário analisa ainda se o software é intuitivo, fácil de ser utilizado e possui alguma falha; e dos desenvolvedores do produto, estes tem a função de considerar todas as características do produto antes deste ser entregue ao usuário, por exemplo, defeitos, qualidades, etc.

26 26 o Qualidade do Processo: O processo de análise da qualidade do software desenvolvido é considerado por muitos engenheiros como sendo de vital importância para um bom funcionamento do projeto, pois, projetos passam por muitas fases e etapas, e caso em alguma destas não for bem realizada, a qualidade pode sofrer algum tipo de consequência; por isso deve-se dar ênfase ao processo de desenvolvimento, e este deve ser melhorado constantemente para que hajam evoluções na qualidade, assim como nos produtos resultantes. o Qualidade no Contexto do Ambiente de Negócios: Aqui o enfoque da observação está voltado para uma perspectiva de negócios, ou seja, a qualidade é mensurada a partir de produtos e serviços que dão suporte ao desenvolvimento de softwares; a partir de pesquisas foi analisado que, ao se melhorar a qualidade do software seu valor comercial também aumenta. Com os constantes avanços tecnológicos, com o crescimento do mercado de Tecnologia da Informação (TI), e com um público alvo cada vez mais exigente, a Organização Internacional de Padronização (ISO) foi criada, esta tinha o intuito de realizar auditorias internas para verificar o funcionamento do sistema de gestão de qualidade (ISO 9000). Pois bem, controlar a qualidade é uma ação que demanda muita responsabilidade, pois, fazer este controle total implica em uma representação de um sistema funcional, onde são integradas atividades como qualidade de desenvolvimento, manutenção além de esforços de melhoria da qualidade Qualidade de Software Como foi visto, o mercado de TI está em constante crescimento e evolução, e, a busca por produtos que ofereçam qualidade é algo cada vez mais almejado pelos usuários; investir na qualidade desses softwares é uma tarefa que está diretamente relacionada a um gerenciamento rigoroso de requisitos, uma gerência efetiva de projetos e um processo de desenvolvimento bem definido, gerenciado e em melhoria contínua. (VASCONCELOS et al., 2006, p. 81).

27 27 No sentido mais geral a qualidade de software deve ser definida como: uma gestão de qualidade efetiva aplicada de modo a criar produto útil que forneça valor mensurável por aqueles que o produzem e para aqueles que o utilizam. (Pressman, 2011, p. 360). Devemos lembrar que os softwares são desenvolvidos por pessoas, e, muitas vezes as limitações humanas fazem com que erros de lógica ou erros de interpretação influenciem no cumprimento das metas estabelecidas; investir na qualidade dos softwares desenvolvidos só traz benefícios as empresas, pois, são evitados retrabalhos e correções de defeitos após o software ser entregue ao usuário, sem contar que há um aumento na produtividade assim como um melhor relacionamento com os clientes ou usuários finais já que há um melhor planejamento e gestão por parte da empresa. Segundo Pressman (2011), existem três definições importantes para medir a qualidade dos softwares: o Gestão da Qualidade: Aqui são estabelecidas informações e metas que darão suporte ao processo de criação do software. o Produto Útil: Caracteriza-se como tal um produto de software, porém, este deve atender as necessidades dos clientes, devem ser isentos de erros além de fornecer confiabilidade. o Agregue Valor tanto para o Fabricante quanto para o Usuário: A empresa desenvolvedora deve disponibilizar o mínimo de atualizações possíveis, ou esta vai perder credibilidade junto ao mercado consumidor de softwares. Para Volpe et al. (2004), desde 1993 a Secretaria de Política de Informática (Sepin) que faz parte do Ministério da Ciência e Tecnologia (MCT) no Brasil vem realizando um acompanhamento de qualidade acerca dos processos de software, e a partir destas foi percebida um progresso significativo na procura de melhoria contínua da qualidade nos processos de desenvolvimento dos softwares brasileiros. Adotar um modelo de qualidade traz benefícios em todos os sentidos para uma organização, por exemplo, Aumento de produtividade, redução no número de defeitos em produtos, maior previsibilidade e visibilidade dos processos, além do atendimento das metas de custo, prazo, funcionalidade e qualidade do produto desenvolvido, além de aumentar a motivação da equipe. (VOLPE et al. 2004, p. 48).

28 28 Atualmente existem diferentes modelos de qualidade que podem ser seguidas por organizações que desenvolvem de software, são elas (Volpe 2004): o Capability Maturity Model (CMM): Desenvolvido pelo Software Engineering Institute (SEI), este modelo descreve um caminho evolucionário no que diz respeito a maturidade; possui cinco níveis de qualidade, sendo assim, quanto maior o nível, maior a maturidade nos processos de desenvolvimento de software de uma empresa. o Capability Maturity Model Integration (CMMI): Também desenvolvido pelo SEI, porém seu foco é na melhoria da maturidade dos processos de softwares em empresas desenvolvedoras. o Project Management Body of Knowledge (PMBoK): Guia de uso contendo as melhores práticas em gerencia de projetos; este guia traduz os conhecimentos mais atuais da prática de gerenciar projetos no mundo inteiro. o Software Engineering Body of Knowledge (SWEBoK): Guia de uso contendo as melhores práticas da engenharia de software. o ISO 9001 Sistema de qualidade: Modelo para garantia da qualidade em projetos, desenvolvimento, produção, instalação e serviços associados: Esta norma é baseada em uma série de princípios de gestão da qualidade, incluindo um forte foco no cliente, a motivação e o envolvimento da gestão, abordagem de processo e melhoria contínua. (ISO 9001: 2008). o ISO Tecnologia da Informação: Avaliação de Processos: Esta norma provê um processo que pode ser empregado para definir, controlar e melhorar os processos de ciclo de vida dos softwares. Este trabalho adotará o modelo de qualidade brasileiro MPS.BR com ênfase no nível G de qualidade; a próxima seção detalhará melhor as funcionalidades deste método Melhoria do Processo de Software Brasileiro (MPS.BR) O MPS.BR foi criado em dezembro de 2003 pela Associação Para Promoção do Software Brasileiro (SOFTEX), esta conta com o apoio do Ministério de Ciência e Tecnologia

29 29 (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e o Banco Interamericano de Desenvolvimento (BID). Seu principal objetivo é a Melhoria do Processo de Software e de Serviços no Brasil, porém, com um atendimento voltado às empresas de pequeno e médio porte. Esta metodologia busca satisfazer as necessidades deste mercado que se encontra em constante expansão; tal programa busca ainda reconhecimento nacional bem como internacional por ser um modelo eficaz e que presta serviço às comunidades desenvolvedoras de software. Como forma de averiguar se este processo está sendo empregado da forma correta, o MPS.BR dispõe de processos e métodos para que sejam realizadas avaliações. Agindo deste modo, embora pareça bobagem, o MPS.BR está contribuindo para que os softwares nacionais possuam certificação de qualidade. O modelo de qualidade MPS.BR, teve sua inspiração em padrões de qualidade nacionail e internacionais; Norma NBR ISO/IEC 12207, a norma internacional ISO/IEC e a ISO/IEC 15504, o que permite considerar portanto, que o modelo está em conformidade com estas normas. (NETO, 2008, p. 57). Este modelo de referência para desenvolvimento de software, define sete níveis de maturidade como nos mostra a figura 2, e de acordo com Fagundes (2014), processos de maturidade de software precisam seguir um conjunto de atividades, métodos, práticas e mudanças, e, as organizações desenvolvedoras são as responsáveis por manter e desenvolver produtos de software baseados nestas atividades. A figura 2, mostra a correspondência entre o CMMI e o MPS.BR.

30 30 Figura 2 Correspondência entre o CMMI e o MPS.BR Fonte: Carvalho (2005). Estes níveis de maturidade determinam uma escala para medir o quão madura uma organização o é, e foram inspirados nos cinco níveis de desenvolvimento criados pelo CMMI. Apesar do padrão proposto pelo CMMI começar pelo nível inicial (1), depois passar para os níveis de repetível (2), definido (3), gerenciado (4) e otimizado (5), este ainda era um padrão muito alto para as micro, pequenas e médias empresas brasileiras, justamente por este motivo, o MPS.BR desenvolveu sete níveis que atendem ao mercado nacional, são eles: o Nível A: Em Otimização; o Nível B: Gerenciado Quantitativamente; o Nível C: Definido; o Nível D: Largamente Definido; o Nível E: Parcialmente Definido; o Nível F: Gerenciado; o Nível G: Parcialmente Gerenciado; Segundo Neto (2008, apud Couto 2007), o MPS.BR possui uma série de vantagens se tomarmos outros métodos de processo como modelo; alguns desses diferenciais são:

31 31 o Os níveis de maturidade propostos pelo MPS.BR, permitem uma implantação mais gradual, mais de acordo com a realidade de micro, pequenas e médias empresas brasileiras que desenvolvem software, além de ser possível visualizar estas melhorias; o Possui compatibilidade com o CMMI, que é um modelo de qualidade reconhecido internacionalmente; o Foi planejando tendo como foco a realidade de empresas nacionais de pequeno e médio porte; o Custo acessível; o Estas qualificações são avaliadas a cada dois anos; Cabe lembrar, que não há critérios contraditórios nos diferentes métodos de processo, apenas foram feitas adaptações que se adequaram melhor a realidade do mercado brasileiro Nível G de Qualidade O nível G é o primeiro nível de maturidade do MR-MPS-SW (SOFTEX, 2013, p. 7). Este deve ser implantado com precaução já que é o início da implantação de melhorias dos processos de software. Mudar a cultura de uma organização é sempre uma tarefa meticulosa, tanto nas empresas que desenvolvem software, como em empresas de qualquer segmento do mercado. Este é justamente o primeiro passo para se implantar o primeiro nível de qualidade, o nível G; em seguida, a empresa deve esclarecer se possui padrões organizacionais. Na maioria dos casos, empresas que desenvolvem software precisam adequar suas metodologias de trabalho para se tornarem organizações orientadas a projetos, e isto ocorre com a evolução dos produtos de software, ser orientado a projetos significa redefinir algumas operações (atividades de rotina) já em andamento, como projeto, estabelecendo objetivos, prazos e escopo para sua execução. Este nível subdivide-se em: o Gerência de Projetos: Tem como propósito estabelecer e manter planos para definição de atividades, recursos e responsabilidades acerca do projeto além de

32 32 corrigir desvios significativos no desenvolvimento do projeto, quando houver; com o crescimento da maturidade da organização, este propósito evolui junto. o Gerência de Requisitos: Tem como propósito gerenciar os requisitos do produto bem como dos componentes do projeto, além disso, é responsável ainda por identificar inconsistências entre estes requisitos, os planos de projeto e os produtos de trabalho. Esta gerência é responsável por controlar os requisitos. 2.4 GERENCIAMENTO DE PROCESSOS DE NEGÓCIOS (BPM) No ramo da engenharia de software, possuir qualidade no produto desenvolvido é algo extremamente importante, uma vez que o produto de software deve satisfazer as necessidades dos usuários; para que isto possa se concretizar, é importante que um modelo de processo de negócios seja seguido, sendo assim, o BPMN (Business Process Moddel and Notation) sobressai-se por prover uma gramática de símbolos, para mapear de maneira padrão todos os processos de negócio de uma organização (SGANDERLA, 2012, p.1) buscando com isto gerar a capacidade de entendimento de todas as partes interessadas no projeto, ou seja, analistas, desenvolvedores e também os usuários do sistema, OMG (2014). De acordo com Sganderla (2012), desde o seu lançamento, o que ocorreu em 2004, organizações do mundo inteiro passaram a utilizar BPMN em seus processos de negócios, e isto fez com que fossem disseminados conceitos a respeito de processos de negócios, atualmente, esta é considerada uma característica chave de qualquer iniciativa BPM (SGANDERLA, 2012, p.1). De acodo com o Guia para Gerenciamento de Processos de Negócios, o CBoK (2013) a maneira correta se se pensar em Business Process Manegement seria: Em vez de pensar em BPM como um processo de melhoria de processos, pense em BPM como um processo de transformação de processos. Isto porque a transformação vai além da melhoria, transformação implica repensar inovar e mudar paradigmas. Transformar é liderar e construir novas formas de geração de valor para os clientes e para a sociedade. (BPM, CBOK, 2013, p. 1).

33 33 Utilizar-se de processos para a realização de tarefas é apenas um meio para atingir um fim. E fazer uso de BPM para se chegar a este fim é uma nova forma de articular e aplicar abordagens, metodologias, estruturas de trabalho, práticas, técnicas e ferramentas para processos, já que estes muitas vezes são tratados de forma isolada, BPM, CBOK (2013). De acordo com Tony Benedict, presidente da ABPMP (Association of Business Process Management Professionals), gerenciamento de processos de negócios muda a forma tradicional em que as empresas estão acostumadas a gerenciar seus fluxos de trabalho, este novo meio, proporciona mudanças rápidas e inovações para otimizar o trabalho, o relacionamento com os clientes, fornecedores e colaboradores, BPM, CBOK (2013). A ABPMP tem sua atenção voltada para os profissionais que adotem este tipo de processo, a fim de que transformem seus ambientes de trabalho, quer sejam estes públicos ou privados, para oferecer produtos e serviços mais eficientes e que possuam menos defeitos, para que assim, os softwares produzidos forneçam maior valor para o usuário. Quando uma empresa resolve adotar BPM como metodologia de trabalho, ela só tende a ganhar, pois a partir deste momento, atividades que envolvem gerenciamento de desempenho tornam-se mais equilibradas, e o uso desta ferramenta de processos torna-se mais vantajosa a medida que a prática de BPM torna-se mais comum na organização, além de agregar mais valor. Com a implantação e prática de ferramentas orientas a processos novas estruturas, assim como papéis organizacionais para oferecer suporte às novas práticas tendem a surgir junto; o BPM, arremete duas principais abordagens, as que são mais orientadas a projetos de processo e a outra que vê BPM como esforço de transformação de processos, figura 3. Ainda que ambas as áreas tenham foco no gerenciamento de processos, tais abordagens geram papéis e responsabilidades distintos. Embora adotar a prática de BPM traga tantos benefícios às organizações, infelizmente existe um grave problema a cerca deste processo; não há pessoas qualificadas e com conhecimento (BPM CBOK, 2013, p. 13) suficiente nesta área para atender as necessidades de empresas e organizações. De acordo com Brett Champlin, fundador da ABPMP Internacional, (BPM CBOK (2013)), uma saída encontrada por estas empresas foi o investimento em treinamento e desenvolvimento profissional, como uma forma de suprir tal necessidade; ele nos diz ainda que algumas empresas

34 34 Estão construindo seus próprios currículos e programas de treinamento e incorporando pessoas iniciantes para trabalhar junto com os poucos profissionais talentosos de BPM que possuem. Outras estão enviando gestores e analistas para treinamento, para começaram a adquirir conhecimentos e habilidades necessários. (BPM CBOK, 2013, p. 13). Vale enaltecer que hoje, a prática de BPM é uma atividade de negócios que só tende a crescer, esta é uma prática estimulante e que vem conquistando o mercado por oferecer soluções rápidas e inovadoras. Como crédito extra, Champlin, fundador da ABMPM Internacional (BPM CBOK (2013)) comenta que vê os profissionais de BPM como novo backgraund de treinamento para profissionais que queiram aprender estas práticas no futuro, como é apresentado na figura 3. Figura 3 Áreas de Conhecimento em BPM Fonte: BPM, CBoK (2013).

35 Tecnologia da Informação Aplicada à Gestão por Processos (BPMS) A mudança do foco de função para processo por parte de empresas e organizações fez com que a procura por sistemas de informações que suportassem este tipo de metodologia ficasse cada vez mais evidente; utilizar-se destes sistemas, fez com que o ambiente organizacional se tornasse mais colaborativo, no sentido de que atividades de monitoramento do desempenho e comunicação entre as pessoas envolvidas no desenvolvimento de softwares tornaram-se mais eficazes. Davenport et al. (2004) nos afirmam o quão importante é ajustar sistemas de informação a processos de negócios, uma vez que as organizações devem buscar melhorias contínuas; estas empresas devem melhorar o suporte informacional além de reavaliarem e reajustarem outros fatores que contribuam para o sucesso de uma gestão orientada a processos. Em certos casos, automatizar os processos organizacionais não surte o efeito esperado pois a automação foi usualmente aplicada aos processos de retaguarda (back office) e às funções administrativas (GONÇALVES, 2000, p. 6-19). Fazer uso de tecnologias wokrflow (conjunto de ferramentas) no ambiente organizacional possibilita que haja integração entre a automação de processos nas organizações, Thives Jr. (2002). Alguns autores consideram BPM como sendo uma evolução da tecnologia workflow, já que BPM é um processo de transformação de processos e integra várias áreas de atuação de uma organização pela lógica de fluxos de trabalho. A tecnologia BPMS deve fornecer suporte a modelagem dos processos de software, como se pode ver na figura 4, além de integração entre os atores (regra de negócios), automatização dos processos e administração destes, uma vez que os processos desenvolvidos necessitam de execução, monitoração e também de análise, como se pode ver na figura 4:

36 36 Figura 4 Fases da Modelagem, adaptado. Fonte: Bizagi (2014). Um BPMS é composto de pelo menos cinco tarefas básicas: o Definição de Processos; o Execução de Processos; o Modelagem Gráfica de Processos; o Controle de Atividades; o Interface do Usuário; e, durante sua execução, os dados obtidos devem ser adquiridos, usados, reutilizados e criados constantemente. Visando automatizar a gestão do processo de negócio, foi proposto neste projeto a integração entre a ferramenta BPMS e o modelo de qualidade MPS.BR nível G, como forma de deliberar a criação de uma ferramenta que auxilie organizações a acompanharem a desenvoltura das fases de seus projetos. Portanto, foi escolhido o software BizAgi Studio, cuja interface principal é ilustrada na figura 5;

37 37 Figura 5 Interface Principal do BizAgi Studio. Fonte: O Autor. BizAgi é um software BPM que possui interface gráfica intuitiva e versátil, facilitando a automação de processos. Tem como objetivo proporcionar resultados imediatos a partir de suas ferramentas, estas dão suporte a modelagem de processos BPMN, regras de negócios, definição de interface com o usuário, portal web de trabalho, além de dar suporte a gerência com ferramentas de otimização e balanceamento de cargas de trabalho, bem como acompanhamento dos indicadores de desempenho de processos, BizAgi (2014). Vale ressaltar que mesmo os processos já tendo sido automatizados, é possível fazer a edição destes de forma prática; isto é bastante útil para as empresas, pois, caso haja a necessidade de modificação, os processos são rapidamente alterados sem gerar danos comerciais, BizAgi (2014). A seguir, será detalhado as funcionalidades desta plataforma de automação de processos, BizAgi (2014): o Curso BPMN Embutido: Model Process é a ferramenta de modelagem de processos oferecida pelo BizAgi, nela é possível identificar detalhadamente as funcionalidades de cada objeto, como mostra a figura 6; quando um desenho é feito, o interlicense identifica quais objetos podem ser conectados, fazendo com que erros sejam impedidos neste primeiro momento, além disso, ao ser finalizada a modelagem, o BizAgi também permite exportar os gráficos para imagem, arquivo PDF, arquivo Microsoft Visio e Word, XPDL e XML (FACCIO apud SANTOS, 2011, p. 30). Como se observa na figura 6:

38 38 Figura 6 BizAgi Studio, Aba do Model Process. Fonte: O Autor. o O Processo é a Aplicação: Com esta plataforma não é necessário desenvolver códigos, pois, a mesma oferece um ambiente para desenvolvimento totalmente gráfico e ainda dispõe de funções como if, else, for, etc. o Acompanhamento Gráfico e online: Para auxiliar as tarefas dos gestores, o BizAgi disponibiliza graficamente da rota pela qual o processo seguiu, qual o responsável por aquela etapa do projeto e em que ponto o projeto se encontra. o Ambiente Web Customizável: Aqui, pode-se ter um acompanhamento completo da situação em que as tarefas se encontram, pode-se ainda interagir diretamente com estas. Diz-se que a visualização do ambiente é customizável pois pode-se utilizar a apresentação dos dados tanto em formato de pastas quanto criando consultas on-line, como presentam as figuras 7.1 e 7.2.

39 39 Figura 7.1 Fase em que um Processo se Encontra. Fonte: O Autor. Figura 7.2 Fase em que um Processo se Encontra. Fonte: O Autor. o Integração Sharepoint Web: Possui fácil integração com páginas como HTML, Java, páginas Wiki, Sharepoint, para publicação das mesmas; isto é importante pois a colaboração na geração de modelos torna o processo mais ágil. 2.5 CONSIDERAÇÕES FINAIS

40 40 Neste capítulo foi apresentada uma visão geral sobre engenharia e modelagem de software, gestão de qualidade e gerenciamento de processos de software. Foi dado ênfase a assuntos como MPS.BR Nível G, que trata da qualidade, BPMS, e o software BizAgi para que assim a modelagem e o desenvolvimento da ferramenta orientada a processos sejam efetuados.

41 41 3 RESULTADOS E DISCUSSÕES Como já foi apresentado em capítulos anteriores, para desenvolver um sistema ou ferramenta de software algumas etapas devem ser seguidas, e, para o desenvolvimento deste projeto não foi diferente. A princípio foi analisado minuciosamente o guia de implementação MPS.BR nível G, desenvolvido pela SOFTEX para que os requisitos pudessem ser levantados. Com base neste guia, foi escolhida a gerência de requisitos para servir como base para o desenvolvimento da ferramenta. A partir da gerencia de requisitos, as fases para o desenvolvimento da ferramenta foram levantadas com plena base neste guia, como é mostrado na tabela 1: Fases Fase_01: Comunicar com o Cliente Fase_02: Levantar Requisitos Fase_03: Definir Requisitos Fase_04: Receber Requisitos Funcionalidades Fase onde a empresa desenvolvedora e a empresa contratante especificam quais serão os meios de comunicação pelos quais ambas se comunicarão durante o desenvolvimento do projeto. Estas comunicações devem ser registradas formalmente em atas, s, ferramentas de comunicação ou outros meios de Nesta etapa, a empresa contratante expressa quais requisitos ela deseja. Esta etapa funciona como garantia de que os requisitos estejam claramente definidos a partir do entendimento dos requisitos levantados. Esta etapa serve para confirmar que os requisitos levantados e definidos têm aprovação da empresa contratante.

42 42 Fase_05: Avaliar Requisitos Fase_06: Registrar Reprovação Fase_07: Registrar Aceite Fase_08: Avaliar Qualidade Técnica Fase_09: Usar Checklist Fase_10: Realizar Reuniões É feita uma avaliação dos requisitos a fim de garantir que os requisitos propostos atendam às necessidades e expectativas da empresa contratante. Caso os requisitos sejam reprovados, um registro de reprovação deve ser obtido pelos fornecedores de requisitos. Este registro deve ser tratado como um marco do projeto. Caso os requisitos sejam aprovados, um registro de aprovação deve ser obtido pelos fornecedores de requisitos. Este registro deve ser tratado como um marco do projeto. A avaliação e aprovação por parte do cliente após o entendimento dos requisitos por si só não é suficiente para que os requisitos sejam refinados e refletidos em modelos de análise e projeto para a codificação. A avaliação dos requisitos deve envolver, além do cliente, também a equipe técnica da organização. Em geral é aconselhável que os requisitos sejam avaliados pela equipe técnica antes de serem submetidos para aprovação pelo cliente para evitar retrabalho ou a apresentação de um documento sem qualidade técnica adequada para o cliente. É interessante que a empresa desenvolvedora faça uso de Checklist em suas atividades para que problemas frequentes sejam percebidos. Realizar reuniões possibilita que as diversas partes envolvidas no desenvolvimento do

43 43 projeto possam opinar, aprovar e se comprometer em relação aos requisitos do projeto. Fase_11: Reavaliar Qualidades Técnicas Fase_12: Documentar Novos Requisitos Fase_13: Classificar no Sistema de Rastreamento Fase_14: Rastrear Dependências Fase_15: Verificar Itens Implementados Caso haja necessidade de modificar algum requisito, a equipe técnica deverá reavalialos. Logo após, são submetidos para aprovação da empresa contratante. Após a reavaliação dos requisitos editados por parte da empresa contratante, um registro de aprovação deve ser obtido pelos fornecedores de requisitos. Este registro deve ser tratado como um marco do projeto. É importante que se tenha um sistema de rastreamento, pois, é neste sistema onde há detalhamento dos requisitos, transformação em modelos, a codificação, o planejamento e a execução de testes são estruturados para garantir a correta execução do projeto, tendo tarefas previstas discriminadas em um cronograma ou conforme previsto pelo processo Gerência de Projetos - GP (Se houver). A criação de um sistema de rastreabilidade tanto pode ser vertical como horizontal; pressupõe-se que diferentes abstrações dos requisitos, documentos relacionados e o código fonte sejam rastreáveis entre si. Os requisitos, dentro do ciclo de vida do projeto, são posteriormente derivados em elementos de análise e projeto e então,

44 44 transformados em código fonte, para só depois serem testados. Fase_16: Avaliar Artefatos Fase_17: Identificar Possíveis Inconsistências Avaliação da consistência entre os requisitos e os produtos de trabalho do projeto. É importante que revisões sejam realizadas a fim de identificar possíveis inconsistências entre os requisitos e os demais elementos do projeto (planos, atividades e produtos de trabalho). Fase_18: Registrar Aceite Após passar por todas as fases de desenvolvimento, e a empresa contratante decidir que não há inconsistências e nem há a necessidade de realizarem-se mudanças, um registro de aprovação deve ser obtido pelos fornecedores de requisitos. Este registro deve ser tratado como um marco no desenvolvimento do projeto. Fase_19: Resolver Possíveis Inconsistências Fase_20: Examinar Possíveis Mudanças Caso haja inconsistências, estas devem ser registradas e ações corretivas executadas a fim de resolvê-las. No caso de haver mudanças, é importante examinar se há consistência em todos os artefatos modificados. Fase_21: Adequar Mudanças ao Escopo Mudanças realizadas devem ser documentadas juntamente aos outros requisitos. Fase_22: Revisar Requisitos Durante o desenvolvimento do projeto, os requisitos podem mudar por uma série de motivos. Desta forma, requisitos adicionais

45 45 podem ser incorporados no projeto, requisitos podem ser retirados ou ainda podem ser editados. Fase_23: Analisar Possíveis Mudanças Fase_24: Analisar Impacto Caso haja necessidade de realizarem-se mudanças nos requisitos, estas devem ser registradas e um histórico das decisões acerca dos requisitos deve estar disponível. São analisados aspectos como: *Influência de outros requisitos; *Expectativa dos interessados; *Esforço; *Cronograma; *Riscos; *Custos; Vale ressaltar que o mecanismo de rastreabilidade bidirecional é de fundamental importância. Fase_25: Editar Requisitos Fase_26: Registrar Reprovação Fase_27: Registrar Aceite Elaboração de um documento onde sejam declarados os requisitos modificados. Caso o cliente ou empresa contratante aprovem os requisitos editados, esta ação é encaminhada para o nível de mudança a fim de resolver este problema. É realizado um registro de reprovação. Este registro deve ser tratado como um marco do projeto. Quando há aceitação do cliente ou empresa contratante, é realizado um registro de aprovação. Este registro deve ser tratado

46 46 como um marco do projeto. Fase_28: Realizar Histórico das Decisões São registras as necessidades de mudanças (se houver), assim como todas as informações tomadas durante o desenvolvimento do projeto. Tabela 1 Fases da Ferramenta. Fonte: Softex (2013), adaptado. Após ter sido feito o levantamento dos requisitos foi realizada a modelagem da ferramenta utilizando notações BPMN no software BizAgi, como serão mostradas nas figuras 8.1 à 8.7; Figura 8.1 Fases da Modelagem, Etapa de Elicitação dos Requisitos. Fonte: O Autor. Figura 8.2 Fases da Modelagem, Etapa de Avaliação dos Requisitos. Fonte: O Autor.

47 47 Figura 8.3 Fases da Modelagem, Etapa de Rastreabilidade Bidirecional. Fonte: O Autor. Figura 8.4 Fases da Modelagem, Etapa de Revisão. Fonte: O Autor. Figura 8.5 Fases da Modelagem, Etapa de Mudança. Fonte: O Autor.

48 48 Figura 8.6 Fases da Modelagem, Etapa de Avaliação por parte do Cliente. Fonte: O Autor. Figura 8.7 Modelagem Completa da Ferramenta. Fonte: O Autor. Ao ser concluída a modelagem dos requisitos, a modelagem dos dados da ferramenta foi implementada, como se pode ver na figura 9: Figura 9 Modelagem de Dados na Ferramenta. Fonte: Autor.

49 49 O software BizAgi diferencia-se por ser intuitivo e completo, além de possibilitar que a interface com o usuário (fachada) também seja implementada, como se percebe na figura 10: Figura 10 Implementação da Fachada. Fonte: O Autor. Não diferente de outras plataformas para desenvolvimento de softwares, o BizAgi também dá suporte a implementação da regra de negócios (algo extremamente importante), como mostra a figura 11:

50 50 Figura 11 Regra de Negócios. Fonte: O Autor. Desenvolver softwares, é sempre uma tarefa realizada em equipe, e, para que cada equipe tenha acesso a sua parte de interesse no desenvolvimento, o BizAgi permite que a possibilidade de criar perfis e papeis, aonde os requisitos possam ser divididos em grupos específicos, como mostra a figura 12:

51 51 Figura 12 Separação dos Grupos de Requisitos. Fonte: O Autor. Tomando como base o modelo de prototipagem de software, o próximo passo tomado foi o teste da ferramenta, mas, antes que se possa acessar o sistema, é preciso logar em uma área de atuação específica de acordo com a função de cada desenvolvedor, o que pode ser observado na figura 13:

52 52 Figura 13 Tela de login. Fonte: O Autor. Após acessar a conta, o desenvolvedor é redirecionado para uma outra tela onde poderá iniciar suas tarefas, como mostra a figura 14: Figura 14 Tela de Afazeres. Fonte: O Autor. Os testes no sistema são realizados como uma forma de revisar os requisitos implementados para que erros e/ou inconsistências possam ser resolvidos. Mudanças realizadas foram documentadas como forma de manter controle do desenvolvimento desta ferramenta. Por fim, a ferramenta proposta neste projeto tem fortes indícios que atenderá aos objetivos geral e específicos, uma vez que esta foi modelada e automatizada tendo como base os princípios do MPS.BR nível G. Como se pode perceber, a ferramenta desenvolvida relacionou Tecnologia da Informação Aplicada ao Processo de Negócios (BPMS) com as boas práticas do MPS.BR nível G, e, definiu um modelo de implantação com tempo específico para cada tarefa, como mostra a figura 15:

53 53 Figura 15 Gráfico para Acompanhamento de Projetos. Fonte: O Autor. Com definição dos fluxos de trabalho e criação de papéis para cada fase da implementação do software, como está explicito nas figuras 16.1 à 16.3: Figura 16.1 Criação e Definição do Papel de Analista. Fonte: O Autor.

54 54 Figura 16.2 Criação e Definição do Papel de Equipe Técnica. Fonte: O Autor. Figura 16.3 Criação e Definição do Papel de Gerência. Fonte: O Autor. Para que possa ser feito o acompanhamento da evolução dos processos, o bizagi gera gráficos onde são descriminadas as tarefas por usuários, além de mostrar quantas tarefas estão em dia bem como as atrasadas e informa quem deve faze-las, como mostra a figura 17:

55 55 Figura 17 Trabalhos em Andamento por Usuário. Fonte: O Autor. Para que possa ser acompanhado o tempo total de um ciclo de um processo uma tabela com tais informações é gerada, como mostra a figura 18: Figura 18 Resumo do Tempo de Ciclo. Fonte: O Autor.

Qualidade na gestão de projeto de desenvolvimento de software

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

Leia mais

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br Qualidade de Software Aula 6 / 2010 Prof. Dr. Luís Fernando Garcia luis@garcia.pro.br www.garcia.pro.br Introdução As três dimensões críticas Introdução Começando MAL CMMI Impeditivos CMMI Desculpas CMMI

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

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza A visão do modelo MPS.BR para Gerência de Projeto - Nível G por Adriana Silveira de Souza Agenda Visão Geral do MPS.BR Processos e Capacidade de Processo Níveis de Maturidade Atributos de Processo Processo

Leia mais

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

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

Leia mais

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

Pós Graduação Engenharia de Software

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

Leia mais

Introdução à 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

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

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI INTRODUÇÃO Aumento da Importância do Software Software está em tudo: Elemento crítico

Leia mais

Introdução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira

Introdução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira Introdução ao MPS.BR Guia Geral Prof. Elias Batista Ferreira IMPORTANTE Este NÃO é um curso oficial do MPS.BR. Este curso NÃO é apoiado pela Softex. Objetivo deste Curso Descrever os processos e resultados

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

Estudo de caso para implantação do modelo MR-MPS-SV

Estudo de caso para implantação do modelo MR-MPS-SV Estudo de caso para implantação do modelo MR-MPS-SV Giovani Hipolito Maroneze 1, Jacques Duílio Branches 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.001 86.057-970

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

Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail.

Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail. Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura O Modelo Wesley Torres Galindo wesleygalindo@gmail.com Agenda O que é? Motivação Organização do MPS.BR Estrutura

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

FACULDADE SENAC GOIÂNIA

FACULDADE SENAC GOIÂNIA FACULDADE SENAC GOIÂNIA NORMA ISO 12.207 Curso: GTI Matéria: Auditoria e Qualidade de Software Professor: Elias Ferreira Acadêmico: Luan Bueno Almeida Goiânia, 2015 CERTIFICAÇÃO PARA O MERCADO BRASILEIRO

Leia mais

Qualidade de software

Qualidade de software Qualidade de software É cada dia maior o número de empresas que buscam melhorias em seus processos de desenvolvimento de software. Além do aumento da produtividade e da diminuição do retrabalho, elas buscam

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte I Agenda Processos CMMI Definição Histórico Objetivos Características Representações

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

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

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

UNIVERSIDADE FEDERAL DA BAHIA

UNIVERSIDADE FEDERAL DA BAHIA UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO MATA62 - Engenharia de Software I Comparação entre Ferramentas de Gerência de Projeto Salvador 2009.1 MATA62

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

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

QUALIDADE DE SOFTWARE AULA N.7

QUALIDADE DE SOFTWARE AULA N.7 QUALIDADE DE SOFTWARE AULA N.7 Curso: SISTEMAS DE INFORMAÇÃO Disciplina: Qualidade de Software Profa. : Kátia Lopes Silva 1 CMM: DEFINIÇÃO Capability Maturity Model Um modelo que descreve como as práticas

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 UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN DEPARTAMENTO: SISTEMAS DE INFORMAÇÃO PLANO DE ENSINO DISCIPLINA: GERÊNCIA DE

Leia mais

UMA PROSTA DE ADEQUAÇÃO DO MS VISUAL STUDIO TEAM SYSTEM (VSTS) PARA O MPS.BR NÍVEIS F e G

UMA PROSTA DE ADEQUAÇÃO DO MS VISUAL STUDIO TEAM SYSTEM (VSTS) PARA O MPS.BR NÍVEIS F e G 1082 X Salão de Iniciação Científica PUCRS UMA PROSTA DE ADEQUAÇÃO DO MS VISUAL STUDIO TEAM SYSTEM (VSTS) PARA O MPS.BR NÍVEIS F e G Agner Macedo Paiva, Bernardo Copstein (orientador) FACIN, PUCRS, Centro

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

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

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

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

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

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos Bacharel em Sistemas de Informação Faculdade de Informática de Presidente Prudente Universidade do Oeste Paulista (UNOESTE) thiago@visioncom.com.br;

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

Fundamentos de Engenharia de Software Professor Rafael Escalfoni

Fundamentos de Engenharia de Software Professor Rafael Escalfoni Escola Superior de Gestão e Tecnologia Fundamentos de Engenharia de Software Professor Rafael Escalfoni Introdução a Engenharia de Software Aula 1 1 Fundamentos em Engenharia de Software Objetivos da disciplina

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

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade

Leia mais

Dificuldades no desenvolvimento de software Características do mercado de software A participação de Minas Gerais no cenário nacional

Dificuldades no desenvolvimento de software Características do mercado de software A participação de Minas Gerais no cenário nacional Promovendo a Melhoria de Processos e a Qualidade de Software em Minas Gerais Ana Liddy Cenni de Castro Magalhães, Fernando Silva Parreiras, Frederico Faria Comitê Gestor do SPIN-BH Direitos reservados

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

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

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

Padrões de Qualidade de Software

Padrões de Qualidade de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software Engenharia de Software I Aula 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de Software) Padrões de Qualidade

Leia mais

Modelo de Qualidade CMMI

Modelo de Qualidade CMMI Modelo de Qualidade CMMI João Machado Tarcísio de Paula UFF - Campus Rio das Ostras Resumo Este trabalho tem como objetivo explicar de forma simples o que é e como funciona o modelo de qualidade CMMI,

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

GESTÃO DE QUALIDADE EM SERVIÇOS NAS MICRO E PEQUENAS EMPRESAS DO RAMO DE SOFTWARE: GARANTIA DE QUALIDADE MPS.BR

GESTÃO DE QUALIDADE EM SERVIÇOS NAS MICRO E PEQUENAS EMPRESAS DO RAMO DE SOFTWARE: GARANTIA DE QUALIDADE MPS.BR GESTÃO DE QUALIDADE EM SERVIÇOS NAS MICRO E PEQUENAS EMPRESAS DO RAMO DE SOFTWARE: GARANTIA DE QUALIDADE MPS.BR Andressa Silva Silvino 1 Jadson do Prado Rafalski 2 RESUMO O objetivo deste artigo é analisar

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

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

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

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

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br PROCESSOS PODEROSOS DE NEGÓCIO ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br POR QUE ESCREVEMOS ESTE E-BOOK? Nosso objetivo com este e-book é mostrar como a Gestão de Processos

Leia mais

Fatores humanos de qualidade CMM E CMMI

Fatores humanos de qualidade CMM E CMMI Fatores humanos de qualidade CMM E CMMI Eneida Rios¹ ¹http://www.ifbaiano.edu.br eneidarios@eafcatu.gov.br Campus Catu 1 Curso de Análise e Desenvolvimento de Sistemas Conteúdos Fatores humanos de qualidade

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

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

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

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

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

A Disciplina Gerência de Projetos

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

Leia mais

Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos. White Paper

Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos. White Paper Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos White Paper TenStep 2007 Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos Não há nenhuma duvida

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

Padrões de Qualidade de Software e Métricas de Software

Padrões de Qualidade de Software e Métricas de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software e Métricas de Software Engenharia de Software I Aula 3 e 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de

Leia mais

Introdução à Engenharia de. Software. Introdução à Engenharia de. Software. O que é a Engenharia de Software? Software

Introdução à Engenharia de. Software. Introdução à Engenharia de. Software. O que é a Engenharia de Software? Software Introdução à Engenharia de Gidevaldo Novais (gidevaldo.vic@ftc.br) Introdução à Engenharia de Objetivo Depois desta aula você terá uma noção geral do que é a engenharia de software e dos seus objetivos

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

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP Versão 2.0.0 Janeiro 2014 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 3ª Edição (a publicar)

Leia mais

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL Porto Alegre, Agosto de 2008. Sumário Apresentação Programa MPS.BR Reutilização no MPS.BR Gerência de reutilização Desenvolvimento para reutilização

Leia mais

Qualidade de Processo de Desenvolvimento de Software

Qualidade de Processo de Desenvolvimento de Software Qualidade de Processo de Desenvolvimento de Software DAS 5316 Integração de Sistemas Corporativos DAS 5316 Integração de Sistemas Corporativos Prof. Ricardo J. Rabelo Conteúdo Introdução & Problemática

Leia mais

Introdução. AULA 2 A Organização empresarial e a gestão de projetos. Tema relevante em diversas áreas

Introdução. AULA 2 A Organização empresarial e a gestão de projetos. Tema relevante em diversas áreas Universidade do Sagrado Coração Introdução a Gestão de Projetos Paulo Cesar Chagas Rodrigues AULA 2 A Organização empresarial e a gestão de projetos Iniciação 30/set/2008 Engenharia de Produto 2 2 Introdução

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

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Francisco Xavier Freire Neto 1 ; Aristides Novelli Filho 2 Centro Estadual de Educação Tecnológica

Leia mais

Avaliação e Melhorias no Processo de Construção de Software

Avaliação e Melhorias no Processo de Construção de Software Avaliação e Melhorias no Processo de Construção de Software Martim Chitto Sisson Centro Tecnológico Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil martim@inf.ufsc.br Abstract. This

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Abstract. Resumo. 1. Introdução Vinicius A. C. de Abreu 1 Departamento de Ciência da Computação - DCC Universidade

Leia mais

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE 1 VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE Elvis Ferreira da Silva* Msc. Marta Alves de Souza** Msc. Helder

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

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

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2 .:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento

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

CMM - Capability Maturity Model

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

Leia mais

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

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

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM M P S. B R : M E L H O R I A D E P R O C E S S O D O S O F T W A R E B R A S I L E I R O A

Leia mais

Desenvolvimento de um software de gerenciamento de projetos para utilização na Web

Desenvolvimento de um software de gerenciamento de projetos para utilização na Web Resumo. Desenvolvimento de um software de gerenciamento de projetos para utilização na Web Autor: Danilo Humberto Dias Santos Orientador: Walteno Martins Parreira Júnior Bacharelado em Engenharia da Computação

Leia mais

Políticas de Segurança da Informação. Aécio Costa

Políticas de Segurança da Informação. Aécio Costa Aécio Costa A segurança da informação é obtida a partir da implementação de um conjunto de controles adequados, incluindo políticas, processos, procedimentos, estruturas organizacionais e funções de software

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

Uma Introdução a Engenharia de Software e Sistemas

Uma Introdução a Engenharia de Software e Sistemas Uma Introdução a Engenharia de Software e Sistemas Centro de Informática - Universidade Federal de Pernambuco Engenharia da Computação Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

MODELOS DE MELHORES GOVERNANÇA DE T.I. PRÁTICAS DA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

MODELOS DE MELHORES GOVERNANÇA DE T.I. PRÁTICAS DA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza MODELOS DE MELHORES PRÁTICAS DA GOVERNANÇA DE T.I. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza MELHORES PRÁTICAS PARA T.I. MODELO DE MELHORES PRÁTICAS COBIT Control Objectives for Information

Leia mais

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação Centro de Ciências Agrárias Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução à Ciência da Computação Introdução à Ciência da Computação COM06850-2015-II Prof.

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

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da

Leia mais

Aula Nº 9 Gerenciamento de Recursos Humanos em projetos

Aula Nº 9 Gerenciamento de Recursos Humanos em projetos Aula Nº 9 Gerenciamento de Recursos Humanos em projetos Objetivos da Aula: Os objetivos desta aula visam tratar da identificação bem como do estabelecimento de uma estrutura organizacional apropriada ao

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

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

GARANTIA DA QUALIDADE DE SOFTWARE

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

Leia mais

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

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

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais