A técnica ORDIT

A técnica ORDIT (Organisational Requirements Definition of Information Technology Systems) 

Geralmente, a análise de sistema convencional  tem foco em definir informação a partir de uma visão mais direcionada para o funcionamento do software. O modo que as pessoas se relacionam com a organização e a organização se relaciona com o ambiente no qual está inserida tem repercussão importante sobre  o processo de construção de sistemas informatizados. Para Mumford [MUM83], ORDIT é uma metodologia para projetos sóciotécnicos, na qual o sistema é visto como um todo, inserido dentro de um ambiente operacional mais amplo, tendo o usuário como uma parte integrante do sistema. Requisitos organizacionais são resultantes das interações de sistema  com o contexto social. Algumas fontes de emanação de requisitos são as estruturas de poder, os papéis e posições das pessoas, as obrigações e responsabilidades, o controle e autonomia, os valores e éticas. Portanto, muitos requisitos resultam das estruturas e  políticas adotadas pelas organizações. ORDIT objetiva ajudar os participantes das organizações a definirem alternativas técnicas e o futuro organizacional, fornecendo um processo sistemático,  capaz de suportar gerações de requisitos organizacionais e fornecer métodos e ferramentas associadas que suportam o processo [ORD93, DOB94a, EAS97]. A metodologia descreve stakeholders, relacionamentos, papéis, obrigações, responsabilidades e recursos utilizados.

A doutrina central da filosofia de ORDIT é a defesa de que em um projeto de sistemas não se pode dar atenção somente aos assuntos técnicos, porém sim, aos técnicos e aos humanos. Desse modo, a metodologia ORDIT trata também dos requisitos não-funcionais, e contém um banco de dados de padrões, modelos e conhecimento sobre as características e necessidades de classes diferentes de usuário de computador.

Segundo Dobson [DOB94b], são objetivos da metodologia  ORDIT:

•  criar uma metodologia de apoio à comunidade de stakeholders que deseja considerar o uso da tecnologia da informação para desenvolvimento de software a partir de uma visão organizacional;  
•  capturar e representar requisitos organizacionais para os futuros sistemas sóciotécnicos, levando em consideração tanto requisitos organizacionais como individuais;  
•  modelar a organização e sistemas de informação;
•  modelar futuros alternativos e avaliar o ajuste deles com as exigências de diferentes stakeholders;  
•  produzir uma especificação que representa as mudanças organizacionais e os requisitos do sistema.          
A Figura 3.1 apresenta os elementos básicos da linguagem de modelagem proposta no ORDIT.

A Figura 3.1 mostra que em ORDIT é possível examinar os tipos de relações entre entidades iguais e diferentes. Examinando esses relacionamentos, pode-se começar a entender como ocorre a influência das atividades, dos recursos e dos agentes. Uma atividade é uma operação que se relaciona com as mudanças de estado do sistema, que podem ser visíveis para um ou mais agentes.  Recurso  pode ser de dois tipos: de  consumo e  não-consumível.  Recursos de consumo são objetos como matérias-primas, tempo ou dinheiro, e recursos não-consumíveispodem incluir informação, serviços de telecomunicação etc. Por fim,  agente pode ser considerado como um manipulador primário  do estado ou estrutura do sistema e é o único objeto que, por uma atividade, pode criar, modificar ou destruir outros objetos.

EXTREME PROGRAMMING

O Extreme Programming é um modelo de desenvolvimento de software, criado

em 1996, por Kent Bech, no Departamento de Computação da montadora de carros Daimler Crysler, ele possui muitas diferenças em relação a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos dinâmicos. O XP é um conjunto bem definido de regras, que vem ganhando um grande número de adeptos e por oferecer condições para que os desenvolvedores respondam com eficiência a mudanças no projeto, mesmo nos estágios finais do ciclo de vida do processo, devido a quatro lemas adotados por seus seguidores, que correspondem a quatro dimensões a partir das quais os projetos podem ser melhorados. São eles: Comunicação, Simplicidade, FeedBack e Coragem.

No entanto, o XP não deve ser aplicado a qualquer tipo de projeto. O grupo de

desenvolvedores deve formar uma equipe de 2 a 10 integrantes, que devem estar por dentro de todas as fases do desenvolvimento. É necessário realizar vários testes, às vezes, alterar o projeto em decorrência destes. A equipe tem de ser bastante interessada e pró-ativa, para assegurar a alta produtividade, e o cliente deve estar sempre disponível para tirar dúvidas e tomar decisões em relação ao projeto.

Seguindo os requisitos expostos, anteriormente, o XP poderá trazer inúmeros

benefícios ao mercado, de forma que o processo de desenvolvimento se torne mais ágil e flexível. Um desses benefícios é a agilidade no Planejamento (Planning Games) de não definir uma especificação completa e formal dos requisitos, ao contrário das metodologias tradicionais. Outro é a produção de sistemas simples que atendam aos atuais requisitos, não tentando antecipar o futuro e permitindo atualizações freqüentes em ciclos bastante curtos.

A comunicação com o cliente, no XP, mostra-se mais intensa que nos métodos

tradicionais, devendo o cliente estar sempre disponível para tirar as dúvidas, rever requisitos e atribuir prioridades, utilizando-se de sistemas de nomes, em vez de termos técnicos para facilitar a comunicação. As equipes devem manter-se integradas com os projetos, melhorando a comunicação e a produtividade. Uma outra característica importante do XP é que o código é sempre escrito em duplas, visando a melhorar a qualidade do código por um custo muito baixo, às vezes menor do que o desenvolvimento individual. O código deve estar padronizado, para que todos na equipe possam entender o que está sendo escrito e possa ser validado durante todo o desenvolvimento, tanto pelos desenvolvedores quanto pelos clientes, a fim de se saber se os requisitos estão ou não sendo atendidos.

EXTREME PROGRAMMING, INDÚSTRIA E UNIVERSIDADE

A inclusão de metodologias de desenvolvimento ágil nos currículos de referência

das universidades é de grande valia para a indústria, que busca maior produtividade com a utilização do XP, mas que esbarra na falta de desenvolvedores qualificados para aplicar tais metodologias. A seguir, serão apresentado os conceitos do XP, descritos anteriormente, que podem ser aplicados nas universidades e, consequentemente, fornecer mão-de-obra necessária à indústria.

EXTREME PROGRAMMING: CONCEITOS

Valores

· Comunicação

· Simplicidade

· Feedback

· Coragem

· Respeito

Princípios Básicos

· Feedback rápido

· Simplicidade

· Mudanças incrementais

· Abraçar mudanças

· Trabalho de qualidade

Práticas

Para aplicar os valores e princípios durante o desenvolvimento de software, o XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

Jogo de Planeamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planeamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e, assim, ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem colocadas em produção.

Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projecto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versoes chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.

Metáfora (Metaphor): Procurar facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas de tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

Projecto Simples (Simple Design): Simplicidade é um princípio do XP. Projeto

simples significa dizer que caso o cliente tenha pedido que na primeira versão

apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter

acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projecto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.

Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.

Testes de Aceitação (Customer Tests): São testes construídos pelo cliente em

conjunto com analistas e testadores, para aceitar um determinado requisito do

sistema.

Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter

ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto.

Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos de modo a efetuar reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.

Posse Coletiva (Collective Ownership): O código fonte não tem dono e ninguém

precisa ter permissão concedida para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é criada com alguém sendo iniciado na liguagem e a outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor

acompanha ajudando a desenvolver suas habilidades. Dessa forma o programa

sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs).Com isto, procura-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Dessa forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.

Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

Refatoração (Refactoring): É um processo que permite a melhoria contínua da

programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refactorizar melhora a clareza (leitura) do código, dividido em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte.

Integração Contínua (Continuous Integration): Sempre que realizar uma nova

funcionalidade, nunca esperar uma semana para integrar na versão actual do

sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da progra

Fonte: intranet.fainam.edu.br

E.K.D - Enterprise Knowledge Development

É uma metodologia recente que auxilia em analisar, entender, desenvolver e documentar uma organização e seus componentes usando a Modelagem Organizacional, podendo envolver todas as áreas de uma organização, fazendo-a uma classificação dos requisitos para que a organização (composição) fique em sintonia com a empresa (negocio).

A modelagem organizacional traz grandes benefícios à engenharia de requisitos de software, à medida.

Que auxiliam o entendimento dos aspectos sociais, organizacionais, técnicos, jurídicos e econômicos.

(PADUA, 2002)

 Metodologia E. K. D

Na modelagem organizacional do EKD são tratadas algumas questões como:

· Estratégias do plano de negócios;

· Análise e definição dos conceitos e regras de negócio;

· Reengenharia dos processos de negócio;

· Planejamento de pessoal.

Tendo como objetivo “desenhar”  o modelo organizacional e obter o melhor entendimento para resolver problemas e desenvolver o conhecimento da organização.

 “A técnica de Modelagem Organizacional EKD facilita a compreensão do ambiente empresarial e é  conhecida como uma atividade valiosa para a engenharia de requisitos” Pádua (2001)

Pode se utilizar o mesmo, tanto em negócios já existentes ou em situaçoes futuras que possam vir a ocorrer no negocio.

Bubenko et al (2001),cita alguns benefícios tradizidos na utilizaçao de metodologia E.K.D:

· Compreender melhor o negócio;

· Facilitar a aprendizagem organizacional e a comunicação sobre questões essenciais;

· Auxiliar a compreender as capacidades e processos dentro da organização;

· Melhorar a comunicação entre usuários e desenvolvedores do sistema de informação;

· Desenvolver uma descrição estruturada do negócio

· Auxiliar os desenvolvedores do sistema de informação e usuários na determinação dos requisitos e objetivos do sistema;

· Estabelecer uma descrição dos objetivos, entidades, processos e requisitos que é mais consistente e completa do que uso desta descrição em forma de texto;

· Gerar uma base de documentos em computador (repositório de conhecimento) que pode ser usado para:

- Argumentar sobre o negócio;

- Discutir as mudanças e evolução do negócio;

- Traçar uma sequencia de componente e decisões que conduzem a várias implementações de decisões e componentes de sistema de informação.

O EKD tem alguns modelos que analisam a organização e suas exigências partir de perspectivas interrelacionadas que construirão o modelo da empresa segundo o aspecto representado por cada um dos Modelos,dos quais os mais conhecidos são: Modelo de objetivos; Modelo de Regras de negócio; Modelo de Processos de negócio; Modelo de Conceitos; Modelo de Requisitos e componentes técnicos; e Modelo de Atores e Recursos.

Sub-Modelos do Enterprise Knowledge Development – E. K. D.

Modelos de objetivos

Apresenta uma descrição do que a organização deseja alcançar, impedir ou evitar. O objetivo é mostrar pontos como: o caminho que a organização deve seguir, prioridades dos objetivos estabelecidos e qual o relacionamento dos objetivos com os problemas, ameaças e oportunidades encontrados na busca de suas realizações.

Modelo de regras de negócio

 Define e apresentar as regas de negócio. A consistência e formulação dessas regras dependem do que foi estabelecido no modelo de objetivos, esclarecendo questões do tipo:

· Quais regas afetam os objetivos da organização;

· Como cada regra do negócio está relacionada com os objetivos;

· Como os objetivos são apoiados pelas regras;

· Quais são as políticas declaradas.

Modelo de Processo de negócio

Definir os processos organizacionais, mostrar a forma de interação e manuseio das informações e materiais.

Outra finalidade desse modelo é apresentar quais são as entradas necessárias em termos de informação ou material. A elaboração do modelo de processo de negócios permite esclarecer:

· Quais são as atividades e processos reconhecidos na organização em concordância com as metas;

· De que forma os processos deveriam ser realizados e quais as informações necessárias.

       Modelos de Conceitos

Deve incluir componentes pelos quais se pode descrever o conteúdo de diferentes conjuntos de informações e fluxos do processo de negócios, servindo como um dicionário, pois também define as entidades e os dados da aplicação sob um aspecto conceitual.

     

Modelo de atores e recursos

Define os tipos de atores e recursos envolvidos na atividade da empresa. Descreve como diferentes atores e recursos se relacionam uns com os outros e como ele se relacionam com os componentes do modelo de objetivos.

Atores e recursos podem ser:

· Indivíduos: caracterizando uma pessoa na empresa. Por exemplo: João, Maria, etc...

Indivíduos são identificados pelos seus nomes.

· Unidade organizacional: pode representar toda a estrutura organizacional da empresa, como um grupo, ou departamento, divisão, seção, projeto, equipe, etc... Exemplo: Departamento de Planejamento, Assistência técnica.

· Recurso não humano: podem ser máquinas ou sistemas de diferentes tipos. Por exemplo: Aparelho de FAX, “MS Word”.

· Funções: podem ser utilizados pelos Indivíduos e Unidades organizacionais em diferentes contextos. Por exemplo: Autor, Controlador, Supervisor, Gerente, Chefe de Equipe.

Modelo de requisitos e componentes técnicos

Esse modelo define a estrutura e propriedades do sistema de informação para apoiar as atividades de negócio.

Os modelos de Objetivos, Regras de Negócio, Processo de Negócios e Atores e Recursos é uma descrição inicial para a empresa, porém para desenvolver um sistema de informação que suporte esses processos, existe a necessidade de se direcionar a atenção para o sistema técnico que é necessário para apoiar os objetivos, processos e atores da organização.

Fonte: http://pedreirodainformatica.blogspot.com.br

RUP (Rational Unified Process)

Visão Geral

O Rational Unified Process® (também chamado de processo RUP®) é um processo de engenharia de software.  Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento.  Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis.

A figura acima mostra a arquitetura geral do RUP.

O RUP tem duas dimensões:

A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos.

A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.

O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações iniciais, dedicamos mais tempo aos requisitos. Já nas iterações posteriores, gastamos mais tempo com implementação.

Fases

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma avaliação (Atividade: Revisar Marcos do Ciclo de Vida) para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

Fases de Planejamento

As fases não são idênticas em termos de programação e esforço. Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio tamanho deve prever a seguinte distribuição de esforço e programação:

	Iniciação	Elaboração	Construção	Transição
Esforço	~5 %	20 %	65 %	10%
Programação	10 %	30 %	50 %	10%

que pode ser descrito graficamente como

Para um ciclo de evolução, as fases de iniciação e de elaboração seriam bem menores. Ferramentas que automatizam parte do esforço de Construção podem amenizar isso, tornando a fase de construção muito menor do que as fases de iniciação e de elaboração juntas.

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases produz uma geração do software. A menos que produto "desapareça", ele irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas diversas fases. Esses ciclos subseqüentes são chamados de ciclos de evolução. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante. Normalmente, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a definição e a arquitetura básicas do produto foram determinadas por ciclos de desenvolvimento anteriores.   São exceções a essa regra os ciclos de evolução em que ocorre uma redefinição significativa do produto ou da arquitetura.

Iniciação ou Concepção: ênfase no escopo do sistema;

Elaboração: ênfase na arquitetura;

Construção: ênfase no desenvolvimento;

Transição: ênfase na implantação.

As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definido enquanto as fases são objetivas.

Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e documentam o projeto, além de permitir melhor acompanhamento.

Fase de Concepção

A fase de iniciação ou concepção contém os workflows necessários à concordância dos stakeholders - as partes interessadas - com os objetivos, a arquitetura e o planejamento do projeto. Se essas partes interessadas tiverem bons conhecimentos, pouca análise será requerida. Caso contrário, será exigida uma análise mais elaborada. Nesta fase, os requisitos essenciais do sistema são transformados em casos de uso. O objetivo não é fechá-los em sua totalidade, mas apenas aqueles necessários à formação de opinião. A etapa é geralmente curta e serve para definir se é viável continuar com o projeto e definir os riscos e o custo deste último. Um protótipo pode ser feito para que o cliente possa aprovar. Como cita o RUP, o ideal é que sejam feitas iterações, mas estas devem ser bem definidas quanto à sua quantidade e aos objetivos.

Fase de Elaboração

A fase de elaboração será apenas para o projeto do sistema, buscando complementar o levantamento / documentação dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os projetos e inicia a versão do manual do usuário. Deve-se aceitar: Visão geral do produto (incremento + integração) está estável?; O plano do projeto é confiável?; Custos são admissíveis?

Fase de Construção

Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa. Os testes beta são realizados no início da fase de Transição.

Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem "baseline".

Fase de Transição

Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de implantação e entrega, acompanhamento e qualidade do software. Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação do cliente. Nesta fase também é realizada a capacitação dos usuários.

O Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo de reparar o defeito. Os testes são realizados ao longo de quatro dimensões da qualidade:confiabilidade, funcionalidade, desempenho da aplicação, e o desempenho do sistema. Para cada uma destas dimensões da qualidade, o processo descreve como você passar pelo teste do ciclo de planejamento, projeto, implementação, execução e avaliação.

O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o software para seus usuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, a embalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação de ajuda e assistência aos usuários. Embora as atividades de implantação estejam principalmente centradas em torno da fase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação, no final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm menos detalhes do que outros workflows.

Três Disciplinas de Apoio/Suporte

Disciplina de Ambiente

O ambiente enfoca as atividades necessárias para configurar o processo para um projeto. Ele descreve as atividades necessárias para desenvolver as diretrizes de apoio a um projeto. A proposta das atividades de ambiente é prover à organização de desenvolvimento de software os processos e as ferramentas que darão suporte à equipe de desenvolvimento. Se os usuários do RUP não entendem que o RUP é um framework de processo, eles podem percebê-lo como um processo pesado e caro. No entanto, um conceito-chave dentro do RUP foi que o processo RUP pode e, muitas vezes, deve ser refinado. Este foi inicialmente feito manualmente, ou seja, por escrito, um documento de "caso de desenvolvimento" que especificou o processo refinado para ser utilizado. Posteriormente, o produto IBM Rational Method Composer foi criado para ajudar a tornar esta etapa mais simples, engenheiros de processos e gerentes de projeto poderiam mais facilmente personalizar o RUP para suas necessidades de projeto. Muitas das variações posteriores do RUP, incluindo OpenUP/Basic, a versão open-source e leve do RUP, são agora apresentados como processos distintos, por direito próprio, e atendem a diferentes tipos e tamanhos de projetos, tendências e tecnologias de desenvolvimento de software. Historicamente, como o RUP, muitas vezes é personalizado para cada projeto por um perito do processo RUP, o sucesso total do projeto pode ser um pouco dependente da capacidade desta pessoa.

Disciplina de Configuração e Gerência de Mudança

A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos específicos: de configuração, de solicitações de mudança, e de status e medição.

Gerenciamento de configuração: A gestão de configuração é responsável pela estruturação sistemática dos produtos. Artefatos, como documentos e modelos, precisam estar sob controle de versão e essas alterações devem ser visíveis. Ele também mantém o controle de dependências entre artefatos para que todos os artigos relacionados sejam atualizados quando são feitas alterações

Gerenciamento de solicitações de mudança: Durante o processo de desenvolvimento de sistemas com muitos artefatos existem diversas versões. O CRM mantém o controle das propostas de mudança

Gerenciamento de status e medição: Os pedidos de mudança têm os estados: novo, conectado, aprovado, cedido e completo. A solicitação de mudança também tem atributos como a causa raiz, ou a natureza (como o defeito e valorização), prioridade, etc. Esses estados e atributos são armazenados no banco de dados para produzir relatórios úteis sobre o andamento do projeto. A Rational também tem um produto para manter a solicitações de mudança chamado ClearQuest. Esta atividade têm procedimentos a serem seguidos

Disciplina de Gerência de Projeto

O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa granularidade ou planos de Fase que descreve todo o projeto, e uma série de alta granularidade ou planos de Iteração que descrevem os passos iterativos. Esta disciplina concentra-se principalmente sobre os aspectos importantes de um processo de desenvolvimento iterativo: Gestão de riscos; Planejamento um projeto iterativo através do ciclo de vida e para uma iteração particular; E o processo de acompanhamento de um projeto iterativo, métricas. No entanto, esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de projetos.

Fonte: http://www.wthreex.com/rup
 http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process

Processo de Software

Um processo de software pode ser visto como o conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de software. Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas, os procedimentos necessários, a habilidade, o treinamento e a motivação do pessoal envolvido.

Definição de Processos

Há vários aspectos a serem considerados na definição de um processo de software. No centro da arquitetura de um processo de desenvolvimento estão algumas atividades chaves: análise e especificação de requisitos, projeto, desenvolvimento e testes, que são a base sobre a qual o processo de desenvolvimento deve ser construído. Entretanto, a definição de um processo envolve a escolha de um modelo de ciclo de vida, o detalhamento (decomposição) de suas macro-atividades, a escolha de métodos, técnicas e roteiros (procedimentos) para a sua realização e a definição de recursos e artefatos necessários e produzidos.

Um processo de software não pode ser definido de forma universal. Para ser eficaz e conduzir à construção de produtos de boa qualidade, um processo deve ser adequado ao domínio da aplicação e ao projeto específico. Deste modo, processos devem ser definidos caso a caso, considerando-se as especificidades da aplicação, a tecnologia a ser adotada na sua construção, a organização onde o produto será desenvolvido e o grupo de desenvolvimento.

Em suma, o objetivo de se definir um processo de software é favorecer a produção de sistemas de alta qualidade, atingindo as necessidades dos usuários finais, dentro de um cronograma e um orçamento previsível.

A escolha de um modelo de ciclo de vida (ou modelo de processo) é o ponto de partida para a definição de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macroatividades básicas, estabelecendo precedência e dependência entre as mesmas.

Um modelo de ciclo de vida pode ser entendido como passos ou atividades que devem ser executados durante um projeto. Para a definição completa do processo, a cada atividade, devem ser associados técnicas, ferramentas e critérios de qualidade, entre outros, formando uma base sólida para o desenvolvimento. Adicionalmente, outras atividades tipicamente de cunho gerencial, devem ser definidas, entre elas atividade de gerência e de controle e garantia da qualidade.

São fatores que influenciam a definição de um processo:

• Tipo de software (sistema de informação, sistema de tempo real, etc.);

• Paradigma (estruturado, orientado a objetos, etc.);

• Domínio da aplicação;

• Tamanho;

• Complexidade;

• Características da equipe...

Embora diferentes projetos necessitem de processos com características específicas para atender às

suas particularidades, é possível estabelecer um conjunto de ativos de processo (sub-processos, atividades, sub-atividades, artefatos, recursos e procedimentos) a ser utilizado na definição de processos de software de uma organização. Essas coleções de ativos de processo de software constituem o chamado processo padrão de desenvolvimento de software. Processos para projetos específicos podem, então, ser definidos a partir da instanciação do processo de software padrão da organização, levando em consideração suas características particulares. Esses processos instanciados são ditos processos de projeto.

De fato, o modelo de definição de processos baseado em processos padrão pode ser estendido para comportar vários níveis. Primeiro, pode-se definir um processo padrão da organização, contendo os ativos de processo que devem fazer parte de todos os processos de projeto da organização. Esse processo padrão pode ser especializado para agregar novos ativos de processo, considerando aspectos, tais como tecnologias de desenvolvimento, paradigmas ou domínios de aplicação. Assim, obtêm-se processos mais completos, que consideram características da especialização desejada. Por fim, a partir de um processo padrão ou de um processo especializado, é possível instanciar um processo de projeto, que será o processo a ser utilizado em um projeto de software específico. Para definir esse processo devem ser consideradas as particularidades de cada projeto.

Para apoiar a definição de processos, diversas normas e modelos de qualidade de processo de software foram propostas, dentre elas: ISO9001, ISO/IEC 12207, ISO/IEC 15504, CMM, CMMI e MPS.BR. O objetivo dessas normas e modelos de qualidade é apontar características que um bom processo de software tem de apresentar, deixando a organização livre para estruturar essas características segundo sua própria cultura.

Fonte: www.fag.edu.br

Modelo Cascata, Linear ou Clássico

   O modelo cascata descreve um método de desenvolvimento que é linear e seqüencial. Na primeira vez que uma fase de desenvolvimento é completada, o desenvolvimento prossegue para a próxima fase e não há retorno. A vantagem do desenvolvimento cascata é que ele permite controle departamental e gerencial. Um planejamento pode ser atribuído com prazo final para cada estágio de desenvolvimento e um produto pode prosseguir no processo de desenvolvimento,  teoricamente ser entregue no prazo. O desenvolvimento move do conceito, através do projeto (design), implementação, teste, instalação, descoberta de defeitos e termina com a operação e manutenção. Cada fase de desenvolvimento prossegue em uma ordem  estrita, sem qualquer sobreposição ou passos iterativos. (PRESSMAN, 2006) 

   A desvantagem do desenvolvimento em cascata é que ele não permite muita flexibilidade ou revisão. A primeira vez que uma aplicação está em estágio de teste é muito difícil retornar e mudar alguma coisa que não foi bem pensada no estágio conceitual. 

   O modelo cascata inicia de uma abordagem orientada a projetos para a engenharia de software. O projeto é considerado uma tarefa claramente delineada para a qual os resultados desejados podem ser determinados completamente e sem ambigüidade. 

Pressman (1995) aponta alguns problemas identificados neste ciclo de vida: 

       • Os projetos reais raramente seguem  o fluxo seqüencial que o modelo propõe. Alguma iteração    sempre ocorre e traz problemas na aplicação do paradigma 

      • Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente. O ciclo de vida clássico  exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de muitos projetos 

        • O cliente deve ter paciência. Uma versão de trabalho dos programas não estará disponível até um ponto tardio do cronograma do projeto. Um erro crasso, se não for detectado até que o programa  de trabalho seja revisto, pode ser desastroso. Peters (2001) aponta vantagens e desvantagens: 

Vantagens: Permitir a gerência do baseline, que identifica um conjunto fixo de documentos produzidos como resultado de cada fase do ciclo de vida. 

Desvantagens: não é capaz de estabelecer  como efetuar engenharia reversa de um sistema existente e faltam noções de  prototipação rápida e desenvolvimento incremental.

 Figura 1. Modelo de processo em Cascata 

Modelos Incremental, Espiral e de Prototipação

 O Modelo Incremental

Barry Boehm sugeriu, tendo em vista as limitações da abordagem tradicional, que o desenvolvimento de sistemas de informação poderia ser administrado numa série de incrementos. Assim, poderia haver uma série de ciclos de vida tradicionais para cada incremento.

O Modelo Incremental foi desenvolvido através da combinação entre os modelos linear e prototipação. O desenvolvimento é dividido em etapas, denominadas “incrementos”, que produzirão incrementalmente o sistema, até a sua versão final.

Em cada incremento é realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema já em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos.

O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente se os requisitos não estão claros inicialmente. Por exemplo: quando o Modelo Incremental é utilizado, o primeiro incremento é normalmente constituído do núcleo do sistema. Isto é, os requisitos básicos são implementados, e os detalhes suprimidos. Esse produto será entregue para uma avaliação, que poderá detectar, inicialmente, problemas que poderiam ser de dimensões muito maiores se detectados somente na entrega do produto final.

Outra vantagem para o desenvolvedor é que, em contato com o sistema, o cliente esclarece seus requisitos e suas prioridades para os próximos incrementos, além de contar com os serviços da versão já produzida.

Outras vantagens são:

• A construção de um sistema menor é sempre menos arriscada que a construção de um grande;
• Se um grande erro é cometido, apenas o último incremento é descartado;
• Reduzindo o tempo de desenvolvimento de um sistema, as chances de mudanças nos requisitos do usuário durante o desenvolvimento são menores.

1.5 O Modelo Espiral

Seguindo a mesma linha do modelo incremental,o modelo foi proposto o modelo EPS (Boehm, 1988) - Evolutionary Spiral Process. Este modelo baseia-se em quatro principais atividades:

• Determinação dos objetivos, alternativas e restrições;
• Análise de risco e prototipação;
• Validação e verificação;
• Planejamento da fase seguinte.

Esta concepção tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma mais completa possível.

Problemas do Modelo espiral 

•          O modelo em espiral, por suas características de avaliação e planejamento baseadas em risco, exige que se tenha gerentes e técnicos experientes.

•          As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais difíceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado. É necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

1.6 Prototipação

Baseado no desenvolvimento de um protótipo com base no conhecimento dos requisitos iniciais para o sistema. O desenvolvimento é feito obedecendo à realização das diferentes etapas de análise de requisitos, o projeto, a codificação e os testes. Não necessariamente estas etapas devem ser realizadas de modo muito explícito ou formal

A definição de todos os requisitos necessários ao sistema pelo cliente ou usuário geralmente é uma tarefa muito difícil. É quase impossível prever como o sistema irá afetar o funcionamento das práticas de trabalho, como será a interação com outros sistemas e que operações dos usuários devem ser automatizadas. Mas para poder testar os requisitos de uma forma mais eficiente, seria necessária a utilização de um protótipo do sistema.

Um protótipo  é uma versão inicial de um sistema de software, que é utilizada para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções. O desenvolvimento rápido de um protótipo é essencial para que os custos sejam controlados e os usuários possam fazer experiências com o protótipo no início do processo de software.

Um protótipo de software apóia duas atividades do processo de engenharia de requisitos:

• Levantamento de requisitos - Os protótipos de sistema permitem que os usuários realizem experiências para ver como o sistema apóia seu trabalho. Eles obtêm novas idéias para os requisitos e podem identificar pontos positivos e negativos do software. Eles podem, então, propor novos requisitos de sistema.
• Validação de requisitos - O protótipo pode revelar erros e omissões nos requisitos propostos. Uma função descrita em uma especificação pode parecer útil e bem-definida. Contudo, quando essa função é utilizada com outras, os usuários muitas vezes acham que sua visão inicial era incorreta e incompleta. A especificação de sistema pode então ser modificada para refletir sua compreensão alterada dos requisitos.

Na maioria dos projetos, o primeiro sistema construído dificilmente será usável. Ele pode ser muito lento, muito grande, desajeitado em uso, ou todos os três. A questão administrativa, não é se deve construir um sistema-piloto e jogá-lo fora. Isso será feito. A única questão é se deve planejar antecipadamente a construção de algo que se vai jogar fora ou prometer entregar isso aos clientes.

O protótipo pode ser oferecido ao cliente em diferentes formas:

• protótipo em papel
• modelo executável em PC retratando a interface homem-máquina capacitando o cliente a compreender a forma de interação com o software;
• protótipo de trabalho que implemente um subconjunto dos requisitos indicados
• programa existente (pacote) que permita representar todas ou parte das funções desejadas para o software a construir

Vantagens da prototipação:

• modelo de desenvolvimento interessante para alguns sistemas de grande porte que representem um certo grau de dificuldade para exprimir rigorosamente os requisitos
• é possível demonstrar a realizabilidade através da construção de um protótipo do sistema
• é possível obter uma versão, mesmo simplificada do que será o sistema, com um pequeno investimento inicial
• A experiência adquirida no desenvolvimento do protótipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido

Problemas da prototipação:

• Quando informamos que o produto precisa ser reconstruído, o cliente  exige que alguns acertos sejam aplicados para tornar o protótipo  um produto; muito freqüentemente, a gerência de desenvolvimento de software cede.
• O desenvolvedor muitas vezes faz concessões de implementação a fim de colocar um protótipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opções e esquecer-se de todas as razões pelas quais elas são inadequadas - a opção menos ideal se tornou então parte integrante do sistema.