Apesar de o CMMI (Capability Maturity Model Integration) prover uma cobertura mais detalhada do ciclo de vida dos produtos que o uso isolado de outros processos de melhoria, ainda assim não pode ser visto como uma metodologia pronta para ser utilizada pelas organizações. Cada organização deve mapear as áreas de processo do nível CMMI desejado (caso a opção seja a representação por estágios, como veremos adiante) à sua metodologia, aos seus métodos e técnicas de desenvolvimento de produtos e sistemas, levando também em consideração os objetivos de negócio da organização. Tanto o CMMI como as demais normas e modelos de qualidade, dizem “o que” e não “como” fazer. Determinar este “como” é um trabalho adicional bastante grande que as organizações devem realizar quando da adoção destas normas. Para isto, normalmente as organizações buscam no mercado empresas de consultoria que possuem experiência na área. Essas consultorias são bastante indicadas porque aumentam significativamente a qualidade e a velocidade dos resultados. Este trabalho pretende facilitar as organizações interessadas na implementação de um modelo de qualidade, fornecendo descrições sobre alguns dos modelos de qualidade mais utilizados atualmente, bem como modelos de processos, guias e formulários que podem ser utilizados diretamente ou como uma base para a implementação do modelo desejado. Embora se aplique à implementação de qualquer modelo de qualidade, mais especificamente, este trabalho destina-se a auxiliar organizações que visem implementar o modelo CMMI nível 2 (doravante usaremos também a abreviação CMMI-N2). Para tanto, descreve de forma mais detalhada este modelo e fornece um caminho para a implementação do mesmo, incluindo a descrição de um processo mínimo de desenvolvimento de software, com base no RUP (Rational Unified Process) e o uso de um modelo de ciclo de vida de melhoria de processos, o IDEAL. Neste trabalho, propõe-se que seja utilizado o modelo IDEAL para a implementação do modelo de qualidade devido ao fato de este modelo ter sido concebido originalmente como um modelo de ciclo de vida para melhoria de processos de software com base no SW-CMM (Capability Maturity Model for Software). Associado a esse modelo, é sugerido que se utilize algumas técnicas e processos de gerência de projetos para cada área de processo do CMMI-N2, visando implantar cada área de processo através de um projeto. Para a implementação são propostos guias, modelos (formulários) de implementação e uma tabela que mapeia todas as áreas de processo do CMMI-N2, seus objetivos, práticas, produtos de trabalho e as ferramentas associadas.

Apesar de o CMMI (Capability Maturity Model Integration) prover uma cobertura mais detalhada do ciclo de vida dos produtos que o uso isolado de outros processos de melhoria, ainda assim não pode ser visto como uma metodologia pronta para ser utilizada pelas organizações. Cada organização deve mapear as áreas de processo do nível CMMI desejado (caso a opção seja a representação por estágios, como veremos adiante) à sua metodologia, aos seus métodos e técnicas de desenvolvimento de produtos e sistemas, levando também em consideração os objetivos de negócio da organização. Tanto o CMMI como as demais normas e modelos de qualidade, dizem “o que” e não “como” fazer. Determinar este “como” é um trabalho adicional bastante grande que as organizações devem realizar quando da adoção destas normas. Para isto, normalmente as organizações buscam no mercado empresas de consultoria que possuem experiência na área. Essas consultorias são bastante indicadas porque aumentam significativamente a qualidade e a velocidade dos resultados. Este trabalho pretende facilitar as organizações interessadas na implementação de um modelo de qualidade, fornecendo descrições sobre alguns dos modelos de qualidade mais utilizados atualmente, bem como modelos de processos, guias e formulários que podem ser utilizados diretamente ou como uma base para a implementação do modelo desejado. Embora se aplique à implementação de qualquer modelo de qualidade, mais especificamente, este trabalho destina-se a auxiliar organizações que visem implementar o modelo CMMI nível 2 (doravante usaremos também a abreviação CMMI-N2). Para tanto, descreve de forma mais detalhada este modelo e fornece um caminho para a implementação do mesmo, incluindo a descrição de um processo mínimo de desenvolvimento de software, com base no RUP (Rational Unified Process) e o uso de um modelo de ciclo de vida de melhoria de processos, o IDEAL. Neste trabalho, propõe-se que seja utilizado o modelo IDEAL para a implementação do modelo de qualidade devido ao fato de este modelo ter sido concebido originalmente como um modelo de ciclo de vida para melhoria de processos de software com base no SW-CMM (Capability Maturity Model for Software). Associado a esse modelo, é sugerido que se utilize algumas técnicas e processos de gerência de projetos para cada área de processo do CMMI-N2, visando implantar cada área de processo através de um projeto. Para a implementação são propostos guias, modelos (formulários) de implementação e uma tabela que mapeia todas as áreas de processo do CMMI-N2, seus objetivos, práticas, produtos de trabalho e as ferramentas associadas.

Apesar de o CMMI (Capability Maturity Model Integration) prover uma cobertura mais detalhada do ciclo de vida dos produtos que o uso isolado de outros processos de melhoria, ainda assim não pode ser visto como uma metodologia pronta para ser utilizada pelas organizações. Cada organização deve mapear as áreas de processo do nível CMMI desejado (caso a opção seja a representação por estágios, como veremos adiante) à sua metodologia, aos seus métodos e técnicas de desenvolvimento de produtos e sistemas, levando também em consideração os objetivos de negócio da organização. Tanto o CMMI como as demais normas e modelos de qualidade, dizem “o que” e não “como” fazer. Determinar este “como” é um trabalho adicional bastante grande que as organizações devem realizar quando da adoção destas normas. Para isto, normalmente as organizações buscam no mercado empresas de consultoria que possuem experiência na área. Essas consultorias são bastante indicadas porque aumentam significativamente a qualidade e a velocidade dos resultados. Este trabalho pretende facilitar as organizações interessadas na implementação de um modelo de qualidade, fornecendo descrições sobre alguns dos modelos de qualidade mais utilizados atualmente, bem como modelos de processos, guias e formulários que podem ser utilizados diretamente ou como uma base para a implementação do modelo desejado. Embora se aplique à implementação de qualquer modelo de qualidade, mais especificamente, este trabalho destina-se a auxiliar organizações que visem implementar o modelo CMMI nível 2 (doravante usaremos também a abreviação CMMI-N2). Para tanto, descreve de forma mais detalhada este modelo e fornece um caminho para a implementação do mesmo, incluindo a descrição de um processo mínimo de desenvolvimento de software, com base no RUP (Rational Unified Process) e o uso de um modelo de ciclo de vida de melhoria de processos, o IDEAL. Neste trabalho, propõe-se que seja utilizado o modelo IDEAL para a implementação do modelo de qualidade devido ao fato de este modelo ter sido concebido originalmente como um modelo de ciclo de vida para melhoria de processos de software com base no SW-CMM (Capability Maturity Model for Software). Associado a esse modelo, é sugerido que se utilize algumas técnicas e processos de gerência de projetos para cada área de processo do CMMI-N2, visando implantar cada área de processo através de um projeto. Para a implementação são propostos guias, modelos (formulários) de implementação e uma tabela que mapeia todas as áreas de processo do CMMI-N2, seus objetivos, práticas, produtos de trabalho e as ferramentas associadas.

As organizações desenvolvedoras de software, na sua maioria, têm grande dificuldade de identificar e adotar um processo adequado de gestão de mudanças de requisitos. Durante todo o ciclo de vida de desenvolvimento de um software existem inúmeras solicitações de mudanças de escopo e de requisitos (técnicos ou não). Isso provoca muitos transtornos aos projetos e aos envolvidos. Por isso, há uma necessidade determinante de que essas organizações utilizem um processo adequado de acompanhamento e de controle de requisitos. Com base nisso, este trabalho procura apresentar uma metodologia de gerenciamento de mudanças dos requisitos, desde a base conceitual, que envolve os requisitos ( tipos, problemas, técnicas de elicitação e visão geral sobre modelo de gerência de requisitos), até a aplicação da metodologia proposta em um estudo de caso. O desenvolvimento deste trabalho teve como objetivo principal desenvolver a estrutura de uma metodologia que fosse de fácil aplicação nas organizações, dando uma noção de como devem ser gerenciadas as mudanças de requisitos, sua documentação, os modelos de documentos a serem utilizados e um exemplo prático de aplicação da metodologia.

As organizações desenvolvedoras de software, na sua maioria, têm grande dificuldade de identificar e adotar um processo adequado de gestão de mudanças de requisitos. Durante todo o ciclo de vida de desenvolvimento de um software existem inúmeras solicitações de mudanças de escopo e de requisitos (técnicos ou não). Isso provoca muitos transtornos aos projetos e aos envolvidos. Por isso, há uma necessidade determinante de que essas organizações utilizem um processo adequado de acompanhamento e de controle de requisitos. Com base nisso, este trabalho procura apresentar uma metodologia de gerenciamento de mudanças dos requisitos, desde a base conceitual, que envolve os requisitos ( tipos, problemas, técnicas de elicitação e visão geral sobre modelo de gerência de requisitos), até a aplicação da metodologia proposta em um estudo de caso. O desenvolvimento deste trabalho teve como objetivo principal desenvolver a estrutura de uma metodologia que fosse de fácil aplicação nas organizações, dando uma noção de como devem ser gerenciadas as mudanças de requisitos, sua documentação, os modelos de documentos a serem utilizados e um exemplo prático de aplicação da metodologia.

As organizações desenvolvedoras de software, na sua maioria, têm grande dificuldade de identificar e adotar um processo adequado de gestão de mudanças de requisitos. Durante todo o ciclo de vida de desenvolvimento de um software existem inúmeras solicitações de mudanças de escopo e de requisitos (técnicos ou não). Isso provoca muitos transtornos aos projetos e aos envolvidos. Por isso, há uma necessidade determinante de que essas organizações utilizem um processo adequado de acompanhamento e de controle de requisitos. Com base nisso, este trabalho procura apresentar uma metodologia de gerenciamento de mudanças dos requisitos, desde a base conceitual, que envolve os requisitos ( tipos, problemas, técnicas de elicitação e visão geral sobre modelo de gerência de requisitos), até a aplicação da metodologia proposta em um estudo de caso. O desenvolvimento deste trabalho teve como objetivo principal desenvolver a estrutura de uma metodologia que fosse de fácil aplicação nas organizações, dando uma noção de como devem ser gerenciadas as mudanças de requisitos, sua documentação, os modelos de documentos a serem utilizados e um exemplo prático de aplicação da metodologia.

Entre os fatores que geram o alto custo da rastreabilidade, está a dificuldade na criação e manutenção de relações precisas entre artefatos. Praticamente todas as metodologias existentes preocupam-se em relacionar artefatos diretamente entre si, o que dificulta o uso de processos automatizados na derivação de novos relacionamentos, bem como na manutenção dos já existentes. Com base nestas observações, o presente trabalho propõe o uso de estruturas intermediárias nos relacionamentos, chamadas de entidades, para representar os interesses tratados pelos artefatos, e derivar, automaticamente, relações complexas entre os mesmos. Este modelo foi avaliado por profissionais da indústria e apresentou-se como solução de rastreamento viável, em comparação com as tradicionais matrizes de rastreabilidade. Espera-se que este sirva como base para soluções inovadoras na área, que ainda é considerada problemática. / The difficulties in creation and maintenance of precise relationships between artifacts are the root cause of traceability high cost. VirtualIy alI existing methodologies propose solutions that relate artifacts directly among themselves, what hinders the use of automated processes to derivate new relationships, as welI as maintaining existing ones automaticalIy. Based on these observations, this work proposes the use of intermediate structures, calIed entities, to represent the interests present on traced artifacts. These entities can be used to derive, automaticalIy, complex relationships between artifacts. The proposed model was evaluated by industry professionals and was considered by them as a viable solution for traceability when compared to the traditional traceability matrices. It is believed that this model will serve as a basis for innovative research solutions in traceability, which is still considered a problematic field.

Entre os fatores que geram o alto custo da rastreabilidade, está a dificuldade na criação e manutenção de relações precisas entre artefatos. Praticamente todas as metodologias existentes preocupam-se em relacionar artefatos diretamente entre si, o que dificulta o uso de processos automatizados na derivação de novos relacionamentos, bem como na manutenção dos já existentes. Com base nestas observações, o presente trabalho propõe o uso de estruturas intermediárias nos relacionamentos, chamadas de entidades, para representar os interesses tratados pelos artefatos, e derivar, automaticamente, relações complexas entre os mesmos. Este modelo foi avaliado por profissionais da indústria e apresentou-se como solução de rastreamento viável, em comparação com as tradicionais matrizes de rastreabilidade. Espera-se que este sirva como base para soluções inovadoras na área, que ainda é considerada problemática. / The difficulties in creation and maintenance of precise relationships between artifacts are the root cause of traceability high cost. VirtualIy alI existing methodologies propose solutions that relate artifacts directly among themselves, what hinders the use of automated processes to derivate new relationships, as welI as maintaining existing ones automaticalIy. Based on these observations, this work proposes the use of intermediate structures, calIed entities, to represent the interests present on traced artifacts. These entities can be used to derive, automaticalIy, complex relationships between artifacts. The proposed model was evaluated by industry professionals and was considered by them as a viable solution for traceability when compared to the traditional traceability matrices. It is believed that this model will serve as a basis for innovative research solutions in traceability, which is still considered a problematic field.

Este trabalho apresenta uma ferramenta para gerenciamento de projetos, priorizando as fases de planejamento e o controle do desenvolvimento de software. Ao efetuar o planejamento de um projeto é necessário estimar o prazo, o custo e o esforço necessário, aplicando técnicas já aprovadas, existentes na literatura, tais como: Estimativa do Esforço, Estimativa de Putnam, Modelo COCOMO, Análise de Pontos por Função, Pontos de Particularidade e PSP. É necessária a utilização de uma ferramenta que automatizem o processo de estimativa. Hoje no mercado, encontram-se várias ferramentas de estimativas, tais como: ESTIMACS, SLIM, SPQR/20, ESTIMATE Professional. O controle do desenvolvimento do projeto está relacionado ao acompanhamento do projeto, do profissional e da própria estimativa de custo e esforço de desenvolvimento. Nenhuma das ferramentas estudadas permitiu o controle do projeto por parte da gerência, por isto esta se propondo o desenvolvimento uma nova ferramenta que permita o planejamento e controle do processo de desenvolvimento. Esta ferramenta deve permitir a comparação entre as diversas técnicas de estimativas, desde que baseadas na mesma medida de tamanho: pontos por função. Para exemplificar o uso desta ferramenta, foram aplicados dois estudos de casos desenvolvidos pela empresa Newsoft Consultoria de Informática.

Os requisitos direcionam o desenvolvimento de software porque são cruciais para a sua qualidade. Como conseqüência tanto requisitos funcionais quanto não funcionais devem ser identificados o mais cedo possível e sua elicitação deve ser precisa e completa. Os requisitos funcionais exercem um papel importante uma vez que expressam os serviços esperados pela aplicação. Por outro lado, os requisitos não funcionais estão relacionados com as restrições e propriedades aplicadas ao software. Este trabalho descreve como identificar requisitos não funcionais e seu mapeamento para aspectos. O desenvolvimento de software orientado a aspectos é apontado como a solução para os problemas envolvidos na elicitação e modelagem dos requisitos não funcionais. No modelo orientado a aspectos, o aspecto é considerado o elemento de primeira ordem, onde o software pode ser modelado com classes e aspectos. As classes são comumente usadas para modelar e implementar os requisitos funcionais, já os aspectos são adotados para a modelagem e implementação dos requisitos não funcionais. Desse modo, é proposta a modelagem dos requisitos não funcionais através das fases do ciclo de vida do software, desde as primeiras etapas do processo de desenvolvimento. Este trabalho apresenta o método chamado FRIDA – From RequIrements to Design using Aspects, cujo objetivo é determinar uma forma sistemática para elicitar e modelar tanto os requisitos funcionais quanto os não funcionais, desde as fases iniciais do ciclo de desenvolvimento. Em FRIDA, a elicitação dos requisitos não funcionais é realizada usando-se checklists e léxicos, os quais auxiliam o desenvolvedor a descobrir os aspectos globais – utilizados por toda a aplicação – bem como, os aspectos parciais que podem ser empregados somente a algumas partes da aplicação. O próximo passo consiste na identificação dos possíveis conflitos gerados entre aspectos e como resolvê-los. No método FRIDA, a identificação e resolução de conflitos é tão importante quanto a elicitação de requisitos não funcionais, nas primeiras fases do ciclo de vida do software. Além disso, é descrito como usar a matriz de conflitos para automatizar esse processo sempre que possível. A extração dos aspectos e sua modelagem visual são características muito importantes, suportadas pelo método, porque elas possibilitam a criação de modelos que podem ser reutilizados no futuro. Em FRIDA, é demonstrado como transformar os requisitos em elementos da fase de projeto (classes e aspectos) e como traduzir esses elementos em código. Outra característica do método FRIDA é que a conexão entre diagramas, que pertencem a diferentes fases do processo de desenvolvimento do software, permite um alto nível de rastreabilidade. Em resumo, FRIDA requer que o desenvolvedor migre de uma visão puramente funcional para outra que contemple também os requisitos não funcionais.