1 – Processo de Software
O Guia PMBOK® define processo como sendo um conjunto de atividades inter-relacionadas realizadas para obter um conjunto especifico de produtos, resultados ou serviços (PMBOK, 2004 pág. 373). Focando no desenvolvimento de software, Ian Sommerville define um processo de software como um conjunto de atividades que leva à produção de um produto de software (Sommerville, 2007 pág. 29). Os processos de softwares são complexos e, como todos os processos intelectuais e criativos, dependem de julgamento humano. Não existe um processo ideal, e várias organizações desenvolvem abordagens inteiramente diferentes, adequadas a sua realidade, para o desenvolvimento de software. Os processos evoluem para explorar as capacidades das pessoas em uma organização e as características específicas dos sistemas que estão sendo desenvolvidos. No caso de alguns sistemas, como os sistemas críticos[1], é necessário um processo de desenvolvimento muito bem estruturado. Nos sistemas de negócios, com requisitos que mudam rapidamente, um processo flexível e ágil é provavelmente mais eficaz (Sommervile, 2007 pág. 42).
Existem muitos processos de software diferentes, porém algumas atividades fundamentais são comuns a todos eles (Sommervile, 2007 pág.43), como:
1. Especificação de Software: define a funcionalidade do software e as restrições sobre sua operação.
2. Projeto e implementação de Software: o software que atenda a especificação deve ser produzido.
3. Validação de software: o software deve ser validado para garantir que ela faça o que o cliente deseja;
4. Evolução de Software: o software deve evoluir para atender às necessidades mutáveis do cliente.
Embora não exista um processo de software “ideal”, existe espaço para o aprimoramento (Sommervile, 2007 pág.43). Os processos podem incluir técnicas obsoletas ou não tirar vantagem das melhores práticas, porém existem processos customizáveis que permitem aliar a boa prática de desenvolvimento, sustentada por um grande arcabouço de métodos, que permitem desenvolver software de qualidade em tempo hábil.
O fator tempo é de grande importância para o desenvolvimento de uma aplicação levando-se em consideração a conjuntura da demanda por sistemas baseados em software para o mundo dos negócios, já que estes operam atualmente em ambiente global, sujeito a rápidas mudanças, e tem de responder a novas oportunidades e mercados, mudanças de condições econômicas e ao surgimento de produtos e serviços concorrentes (Sommervile, 2007 pág. 259). Neste cenário, é praticamente impossível derivar um conjunto completo de requisitos de softwares estáveis. Os processos de desenvolvimento de software baseados em especificações completas de requisitos, projeto, construção e teste de sistema não estão voltados para o desenvolvimento rápido de software (Sommervile, 2007 pág. 260).
Processos de desenvolvimento rápido de software são projetados para criar software útil rapidamente. O software não é desenvolvido e disponibilizado integralmente, mas em uma série de incrementos, e cada incremento inclui uma nova funcionalidade do sistema (Sommervile, 2007 pág. 260).
2 – Processo Unificado Aberto (OpenUP/Basic)
O OpenUP/Basic, descrito neste documento apenas como OpenUP, é baseado no Processo Unificado. Ele aplica uma abordagem iterativa e incremental dentro de um ciclo de vida estruturado e abraça uma filosofia pragmática e ágil que foca na natureza colaborativa do desenvolvimento de software. É um processo objetivo e independente de ferramenta, que pode ser estendido para direcionar uma grande variedade de projetos (OpenUP, 2010). É considerado um processo Mínimo, Completo e Extensível, valorizando a colaboração entre a equipe e os benefícios aos interessados, ao invés da formalidade e entrega de itens desnecessários (OpenUP, 2010). O processo pode ser facilmente entendido através das três camadas, Microincrementos (Micro-increment), Ciclo de Vida de Iteração (Iteration Lifecycle), ciclo de vida do projeto (Project Lifecycle).
O esforço pessoal em um projeto OpenUP está organizado em microincrementos. Eles representam pequenas unidades de trabalho que produzem um passo do progresso do projeto, constante e mensurável (normalmente medido em horas ou dias). O processo aplica a colaboração intensiva à medida que o sistema é desenvolvido incrementalmente, por uma equipe comprometida e auto-organizada. Estes microincrementos fornecem um ciclo de feedback extremamente curto, que direciona decisões adaptativas durante cada iteração (OpenUP, 2010).
O OpenUP divide o projeto em iterações planejadas e com intervalos de tempo definidos, normalmente medidos em semanas. As iterações direcionam a equipe na entrega incremental do valor aos stakeholders[2] de uma forma previsível. O plano de iteração define o que deve ser entregue durante a iteração, e o resultado é uma construção demonstrável ou despachável. As equipes OpenUP se auto-organizam para definir como atingir os objetivos da iteração e entregar o resultado. Elas fazem isso definindo e distribuindo tarefas detalhadas de uma lista de itens de trabalho. O OpenUP usa um ciclo de vida de iteração que estrutura como os microincrementos são aplicados para entregar construções estáveis e coesas do sistema, que progridem incrementalmente na direção dos objetivos da iteração (OpenUP, 2010).
O OpenUP estrutura o ciclo de vida do projeto em quatro fases: Concepção (Inception), Elaboração (Elaboration), Construção (Construction) e Transição (Transition).
O ciclo de vida de projeto fornece aos stakeholders e à equipe de projeto, visibilidade e pontos de decisão durante o projeto. Isto permite uma efetiva supervisão para tomar decisões de “prosseguir ou parar” em momentos apropriados. Um plano de projeto define o ciclo de vida, e o resultado final é uma aplicação passível de ser utilizada (OpenUP, 2010).
Em cada uma das quatro fases do ciclo de vida de um projeto existem marcos (milestones) que determinam formalmente o final de uma fase. Eles proporcionando um ponto de verificação para identificar se o projeto está pronto para prosseguir para a fase seguinte (OpenUP, 2010).
Cada fase corresponde a um período de tempo entre dois marcos. Quando um marco não é cumprido, mais iterações podem ser realizadas antes da fase ser considerada completa. O final da fase de Iniciação (Inception) é o primeiro grande marco do ciclo de vida do projeto. Neste ponto, examina-se a relação custo/benefício e decide-se prosseguir ou cancelar o projeto. O fim da fase de Elaboração (Elaboration) é o segundo marco importante. Neste ponto, é traça-se um mapa dos requisitos, examinam-se os objetivos do sistema e o escopo, escolhe-se a arquitetura, e averiguam-se os principais riscos. O marco é alcançado quando a arquitetura for validada. O final da fase de Construção (Construction) é o terceiro marco importante. Neste ponto, o produto está pronto para ser entregue à equipe de transição. O final da fase de Transição (Transition) é a quarto marco importante. Neste ponto, averigua-se se os objetivos foram atingidos e se um novo ciclo de desenvolvimento deve ser iniciado (OpenUP, 2010).
2.1 – Princípios Fundamentais
O OpenUP está baseado em quatro princípios fundamentais mutuamente suportados:
2.2 – Papéis do OpenUP
Software é criado por pessoas com diferentes interesses e habilidades. As pessoas são o maior patrimônio de uma organização de software (Sommerville, 2007 pág. 391). Elas representam o capital intelectual da empresa. As pessoas nos papéis executam as tarefas que usam e produzem os artefatos. Um ambiente de equipe saudável permite uma colaboração efetiva e exige uma cultura engajada na criatividade e na mudança positiva. Os papéis são a face humana do processo de desenvolvimento de software (OpenUP, 2010).
Os papéis não representam responsabilidades individuais sobre as tarefas ou artefatos e não se limitam a descrever o principal executor de uma tarefa, pelo contrário, os papéis incluem uma perspectiva sobre colaboração fornecendo executores adicionais para cada tarefa. Executar um ou mais papéis pode ajudar as equipes a exprimir diferentes pontos de vista para criar uma solução. Esta perspectiva sobre os papéis fortalece a nova geração de processos de desenvolvimento de software, mais focada na interação das pessoas. Ninguém constrói um bom software sozinho, mas uma equipe trabalhando junto pode fazer coisas extraordinárias (OpenUP, 2010).
2.3 – Produtos de Trabalho e Disciplinas do OpenUP
Na Arquitetura de Métodos Unificada (UMA[4]), um produto de trabalho é um elemento de conteúdo que representa qualquer coisa usada, produzida ou modificada por uma tarefa (OpenUP, 2010). Uma disciplina é uma coleção de tarefas[5] que se relacionam a uma “área de interesse” maior em todo o projeto. O agrupamento de tarefas em disciplinas serve principalmente para ajudar a compreender o projeto dentro de uma visão tradicional em cascata[6]. Embora seja comum executar simultaneamente tarefas que pertençam a várias disciplinas (por exemplo, determinadas tarefas de requisitos são executadas sob a mesma coordenação de tarefas de análise e desenho), separar estas tarefas em disciplinas distintas é uma forma eficaz de organizar o conteúdo, tornando mais fácil a compreensão (OpenUP, 2010).
Abaixo, seguem as disciplinas do OpenUP que fornecem organização dos produtos de trabalho, e seus artefatos:
Explica como criar uma arquitetura, a partir dos requisitos mais significantes. A arquitetura é construída na disciplina de Desenvolvimento.
o Artefato: Caderno de Arquitetura (Archtecture Notebook)
Este artefato descreve o contexto para o desenvolvimento do software. Ele contém as decisões, o raciocínio, as suposições, as explicações e as implicações da formação da arquitetura.
Explica como projetar e implementar uma solução técnica que seja aderente à arquitetura e atenda aos requisitos.
o Artefato: Desenho
Este artefato descreve a realização da funcionalidade necessária para o sistema em termos de componentes e serve como uma abstração do código fonte.
o Artefato: Implementação
Uma versão operacional de um sistema ou de uma parte do sistema que demonstre um subconjunto das capacidades a serem fornecidas no produto final é produzida.
o Artefato: Teste de Desenvolvedor
Instruções que validam se os componentes individuais de software estão funcionando de acordo como o que foi especificado.
Explica como instruir, ajudar e suportar a equipe, ajudando-a a lidar com os riscos e obstáculos encontrados na construção de software. Controla as mudanças nos artefatos, assegurando uma evolução sincronizada do conjunto de Produtos de Trabalho que compõem um sistema de software.
o Artefato: Plano de Iteração
Um plano detalhado que descreve os objetivos, as atribuições de trabalho e os critérios de avaliação para a iteração.
o Artefato: Plano de Projeto
Este artefato registra todas as informações necessárias para gerenciar o projeto. Sua principal parte consiste em um plano genérico, contendo as fases e os marcos do projeto.
o Artefato: Lista de Itens de Trabalho
Este artefato contém uma lista de todo trabalho agendado para ser feito dentro do projeto, bem como o trabalho proposto que pode afetar o produto neste ou em projetos futuros. Cada Item de trabalho pode conter referências a informações que sejam relevantes para realizar o trabalho descrito no item.
o Artefato: Lista de Riscos
Este artefato é uma lista dos riscos conhecidos e existentes no projeto, classificados em ordem de importância e associados com as ações específicas de atenuação ou de contingência.
Explica como elicitar, analisar, especificar, validar e gerenciar os requisitos para o sistema a ser desenvolvido.
o Artefato: Especificação de Requisitos Suplementares
Este artefato captura todos os requisitos do sistema não capturados nos cenários ou nos casos de uso, incluindo requisitos de atributos de qualidade e requisitos funcionais globais.
o Artefato: Visão
Este artefato contém a definição da visão dos stakeholders a respeito do produto a ser desenvolvido, especificada em termos das principais características e necessidades dos stakeholders. Contém um esboço dos principais requisitos vislumbrados para o sistema.
o Artefato: Caso de Uso
Este artefato captura a seqüência das ações executadas por um sistema que tenham um resultado de valor observável para aqueles que interagem com o sistema.
o Artefato: Glossário
Este artefato define termos importantes usados no projeto. Estes termos são a base para a colaboração eficaz com os stakeholders e outros membros da equipe.
o Artefato: Modelo de Caso de Uso
Este artefato captura um modelo das funções desejadas do sistema e de seu ambiente, e serve como um contrato entre o cliente e os desenvolvedores.
Explica como fornecer feedback sobre a maturidade do sistema através do desenho, implementação, execução e avaliação dos testes.
o Artefato: Caso de Teste
Este artefato é a especificação de um conjunto de entradas de teste, condições de execução e resultados esperados, identificados com a finalidade de fazer a avaliação de algum aspecto particular de um cenário.
o Artefato: Registro de Teste
Este artefato coleta a saída capturada durante uma única execução de um ou mais testes para uma única realização do ciclo de teste.
o Artefato: Script de Teste
Este artefato contém instruções passo a passo para realizar um teste, permitindo sua execução. Pode ter a forma de instruções textualmente documentadas que são executadas manualmente ou instruções interpretáveis pelo computador que permitem a execução automatizada de testes.
2.4 – Considerações Importantes
O OpenUP destina-se a pequenas equipes que trabalham juntas no mesmo local. A equipe precisa se engajar em total interação face-a-face diariamente. Os membros da equipe são os stakeholders, desenvolvedores, arquitetos, o gerente de projeto e os testadores. Eles tomam suas próprias decisões a respeito do que devem fazer, quais são as prioridades e como melhor tratar as necessidades dos stakeholders. A organização deve suportar a equipe permitindo-lhes esta responsabilidade. Os membros da equipe colaboram extensivamente. A participação dos stakeholders é crítica para o sucesso da implementação do OpenUP. Os integrantes da equipe participam de reuniões diárias para comunicar o status e possíveis dúvidas do projeto. Os problemas são tratados fora dessas reuniões (OpenUP, 2010).
O OpenUP tem foco na redução significativa dos riscos o mais cedo possível no ciclo de vida. Isto requer reuniões regulares de revisão dos riscos e rigorosas estratégias de atenuação. Todo o trabalho é relacionado, acompanhado e atribuído através da “Lista de Itens de Trabalho”. Os membros da equipe usam este repositório único para registrar todas as tarefas necessárias e acompanhá-las. Isto inclui todas as solicitações de mudança, erros e pedidos dos stakeholders (OpenUP, 2010).
Os casos de uso são usados para elicitar e descrever os requisitos, consequentemente, os membros da equipe devem desenvolver habilidades para escrevê-los bem. Os stakeholders são responsáveis por revisar e certificar que os requisitos estão corretos. Os casos de uso são desenvolvidos colaborativamente (OpenUP, 2010).
Os requisitos arquiteturalmente significantes devem ser identificados e estabilizados na fase de Elaboração de forma que uma arquitetura robusta possa ser criada para ser o núcleo do sistema. Uma alteração em um requisito arquiteturalmente significante que tenha de ser tratada pode surgir posteriormente no desenvolvimento, mas o risco disto acontecer é significativamente reduzido na iteração de Elaboração (OpenUP, 2010).
Os testes são executados várias vezes por iteração, sempre que a solução for incrementada com o desenvolvimento de um requisito, uma mudança ou a correção de um erro. Estes testes ocorrem após os desenvolvedores terem construído a solução (que deve passar pelo teste de unidade) e integrado-a no código base. Estes testes ajudam a garantir que uma construção estável seja criada e esteja sempre disponível à medida que o desenvolvimento progride (OpenUP, 2010).
O OpenUP não inclui conteúdo para implantação e configuração de ambiente de desenvolvimento. Ele é focado em uma única equipe, e estas áreas são normalmente tratadas em nível organizacional ou empresarial (OpenUP, 2010).
3 – Referências
PMBOK, Guia (2004). Project Management Institute (PMI), Terceira Edição.
Sommerville, I. (2007). Engenharia de Software, Oitava Edição, Pearson Addison-Wesley.
Royce, W. W. (1970). “Managing the development of large software systems: concepts and techniques”. Proc. IEEE WESTCON, Los Angeles CA: IEEE Computer Society Press.
OpenUP, (2009) “Open Unified Process”. Versão 1.5.0.4. 10-08 2009, http://epf.eclipse.org, acesso em 15/09/2010.
[1] Sistemas Críticos: sistemas técnicos ou sociotécnicos dos quais as pessoas ou os negócios dependem. Se esses sistemas falharem ao desempenhar seus serviços conforme esperado, podem causar sérios problemas e prejuízos significativos (Sommerville, 2007 pág. 29).
[2] Stakeholders: Papel que deve ser executado por qualquer pessoa que é, ou será afetada materialmente pelo resultado do projeto (OpenUP, 2010).
[3] Neste texto, desenho é usado como tradução de design.
[4] Acrônimo para Arquitetura de Método Unificada. A UMA é uma arquitetura para a concepção, especificação e armazenamento de metadados de métodos e processos.
[5] Uma unidade de trabalho que um papel pode ser solicitado a executar.
[6] O primeiro modelo de desenvolvimento de software publicado. Originou-se de processos mais gerais de engenharia de sistemas (Royce, 1970 pág. 16-34) (Sommerville, 2007 pág. 44).
Bacharel em Ciência da Computação pela Universidade Federal de Alfenas. Desenvolvi durante a graduação pesquisas nas áreas de engenharia de software e processos de desenvolvimento de software. Tenho sólidos conhecimentos em processos de desenvolvimento de software (RUP e OpenUP), análise e coleta de requisitos, métodos ágeis de desenvolvimento (SCRUM e XP), programação utilizando as linguagens Java, C e SQL e modelagem de dados utilizando UML.
You must be logged in to post a comment.
5:37:28 pm
Muito bom o artigo, bastante completo apresenta uma boa base teórica.
Me fez interessar mais pelo estudo do openup