• Autora

    Pós-Graduando em Especialização em Informática – Ênfase Análise de Sistemas pela UFMG, Bacharel em Sistemas de Informação (2006) pela Faculdades Pitágoras (Campus Fadom), técnica em Informática (2002) e em Contabilidade (1998). Atualmente Analista de Suporte Júnior III.

  • Direitos Autorais

    Alguns dos materiais (artigos, pdf’s, link’s) disponíveis ou utilizados na edição desse Blog, foram retirados de páginas da internet. Se acaso, algum desses itens for protegido por direitos autorais, queira o detentor do mesmo, me comunicar por email e o material será imediatamente retirado ou darei os devidos créditos!
  • Categorias

  • Arquivos

  • Análise de Sistemas

    • 13,313 hits

Processo de Desenvolvimento de Sw

sw

SPEM (Software Process Engineering  Metamodel) padrão sobre o processo de desenvolvimento de software, hoje assumido pela OMG, a mesma instituição que definiu  a UML. Da mesma forma que a UML o padrão existente na OMG surgiu de um produto da empresa Rational, que foi comprada pela IBM já há algum tempo, esta transferiu o framework do RUP para uma fundação independente e o seu novo produto na área, o Rational Method Composer utliliza-o.

O RUP, como ainda é chamado, esse produto da IBM, é um software customizável de apoio ao processo de desenvolvimento de sistemas.

Visão Geral

Desenvolvimento iterativo

Administração de requisitos

Geração de software com arquitetura baseada em componentes ou serviços

Utilização de modelos visuais

Verificação contínua de qualidade

Gerenciamento de Mudanças

Framework (estrutura) genérica

Pode ser adaptado para diferentes classes de:

Sistemas de software

Áreas de aplicação

Tipos de organização

Níveis de competência

Tamanhos de projeto

Apesar de ser adaptável o RUP às necessidades de sua empresa muitos ainda o acham muito pesado ($ preço), difícil de ser usado. Essa visão é reforçada pela tendência do uso abordagens ágil.

Algumas características

Baseado em casos de uso

Centrado em arquitetura

Iterativo

Incremental

Customizável

Usa UML

4 P’s do projeto

Um projeto de desenvolvimento em qualquer área visa um produto, através de um processo (conjunto encadeado de atividades, leva a construção de artefatos) nos quais os seus participantes assumem papéis específicos.

O RUP além de automatizar o desenvolvimento de projetos na área de software (é uma ferramenta para os engenheiros de software) tornou-se um padrão.

Ciclo de Vida de Sw

Os sistemas nas organizações são dinâmicos, passam por ciclos durante a toda sua vida. As mudanças que ocorrem, a sua deteriorização fazem com que, com o tempo, as necessidades de seus usuários não sejam mais satisfeitas, fazendo com que a organização invista em um novo projeto de desenvolvimento ou manutenção para vencer mais um ciclo da vida do sistema.

Cada ciclo de vida do software ocorre através de fases (Iniciação, Elaboração, Construção e Transição) e é concluído com um release (Conjunto relativamente completo e consistente de artefatos, prontos para serem executados) do sistema.

Para o processo de desenvolvimento de um software o RUP define um conjunto padronizado de fases. Os diversos ciclos da vida de um sistema caracterizam os vários releases do mesmo (os artefatos produzidos durante o tempo).

Fases, Marcos e Releases

Marco ( Milestones ) – Ponto onde os gerentes tomam decisões de negócios importantes: Continuar / Não continuar, Cronograma, Orçamento, Necessidades do projeto, Sincronismo do projeto. Aqui se encontram os aspectos técnicos e gerenciais.

O término de uma fase, do ponto de vista da gerência do projeto, é sinalizado por um marco (conjunto de artefatos padronizados). Os artefatos técnicos e relatórios gerenciais do marco permitem as definições necessárias quanto à continuidade ou não do projeto. Toda fase tem seu marco correspondente.

FaseIntervalo de tempo entre dois marcos de um processo de desenvolvimento de software.

Mediante tudo isso, o RUP pressupõe que o desenvolvimento seja iterativo, existindo a necessidade de sempre voltar atrás, para que algo seja refeito. Na medida em que o processo caminha releases do software vão sendo obtidos de forma iterativa. Ter somente um release pode custar caro ao fim do processo de desenvolvimento.

Assim no mundo de hoje, desenvolver software é mais um processo experimental (isso é uma verdade em sistemas complexos, envolvendo redes sociais, com pessoas espalhadas por todo o planeta).

Fase Iniciação

* O RUP define para cada um desses papéis (analistas, desenvolvedores, testadores, gerentes, Outros Papéis) a sua responsabilidade na realização dos artefatos necessário e seu envolvimento nas diversas atividades de desenvolvimento, nas diversas fases do processo.

** Implica uma responsabilidade bem definida do papel exercido por alguém,

Leva a um resultado bem definido (artefatos ), baseada em entradas bem definidas ( artefatos ),

Representa uma unidade de trabalho com limites bem definidos,

Usada no planejamento do projeto e na designação de papéis.

Podem ser definidas em níveis diferentes (geral ou detalhado), usadas quando necessárias e permitem a definição de responsabilidades no processo de desenvolvimento de um projeto. Como essa atividade se insere nas fases do desenvolvimento, quem é o responsável por ela, quais os artefatos envolvidos.

Características

Granularidade diferente: podem durar horas ou dias,

Podem ser repetidas várias vezes em diversas iterações,

Podem ser feitas através de um ou mais papéis.

São compostas de passos (steps).

Categorias de passos:

A) De pensamento ——- Formulação

B) De realização ——- Criação / atualização de artefatos

C) De revisão ——- Inspeção de resultados de acordo com algum critério

Atividades complexas – divididas em passos de diversos tipos (sub-atividades). Para sistemas maiores o processo pode ser acompanhado pelos seus passos (em maior detalhe), sistemas com menos complexidade podem ser acompanhados pela atividade mais geral (com menos detalhes).

Categorias RUP

O RUP tem características de tutorial, se você não sabe como fazer uma atividade, ele descreve todos os seus passos, os papéis envolvidos e os artefatos a serem desenvolvidos.

*** É criado, usado, modificado através dos papéis que as pessoas assumem,

Representa uma área de responsabilidade,

É controlado por versões.

Podendo ser compostos de outros artefatos.

Possíveis formas:

Modelo – Diagrama UML (modelo de casos de uso)

Elemento de um modelo (classe)

Documento (relatório da arquitetura do software )

Código fonte

Executáveis

Plano de projeto

Podem ser modelos, diagramas técnicos, relatórios gerenciais, componentes de software, o próprio software no seu todo.

Disciplinas do RUP

Disciplinas RUP

Disciplinas – Conjunto de atividades que envolvem as várias fases e são agrupados de acordo com a sua especificidade dentro da área de desenvolvimento de software ( por exemplo modelagem de processos de negócio).

As disciplinas visão técnica do processo, as fases visão gerencial.

Seqüência de atividades logicamente integradas que produzem um resultado de valor observável que tem a ver com os objetivos principais do projeto de desenvolvimento de software, descritas através do detalhamento do fluxo de trabalho (workflow ).

Para ambientes de desenvolvimento (sistemas) maiores e mais complexos existem profissionais especializados nessas disciplinas em função dos papéis necessários na mesma.

As disciplinas são descritas pelos fluxos de trabalho (workflow) que devem ocorrer em cada fase do RUP. Nesses fluxos de trabalho podemos ver em detalhe o encadeamento das atividades necessárias, os papéis envolvidos e os artefatos de entrada e os de saída.

Descrição do Processo – Estrutura Dinâmica

Cada fase é dividida em Iterações: conjunto distinto de atividades realizadas de acordo com um plano e critérios de avaliação, que resulta num release do software.

As atividades do fluxo de trabalho podem ser executadas várias vezes, em níveis de detalhe diferentes e de forma iterativa (visão dinâmica), obtendo-se vários releases durante o processo de desenvolvimento.

O RUP segue um processo de desenvolvimento iterativo (em espiral), em que você volta nas mesmas fases anteriores de forma crescente (com mais detalhe), refazendo aquilo que seja necessário.

Comparando processos de Sw

É importante saber em cada situação qual é a melhor abordagem a utilizar.

Cascata

Riscos pequenos

Sequencial

Integração e testes posteriores

Pouca Cerimônia

Muita Cerimônia

Documentação mínima

Documentação adequada

Processo leve

Rastreabilidade

Controle de mudanças

RUP Leve, XP Scrum

Iterativo

RUP Mèdio

Guiado pelo risco

RUP Pesado

Integração e testes contínuos

Para se comparar processos de desenvolvimento de software tem-se algumas visões: o nível de cerimônia exigido pelo mesmo. Esta pode ser medida pelo nível de detalhes usado, a formalização dos artefatos e papéis envolvidos, o controle exercido no processo. Processos mais complexos, que exigem maior qualidade, tendem a exigir no seu envolvimento maior cerimônia.

O RUP apresenta uma imagem de ser um processo cerimonioso, apesar de que a IBM tenta vender a idéia que o mesmo possa ser customizado, em níveis diferentes de cerimônia, em função das suas necessidades. Em contra partida o XP é um processo com pouca cerimônia, ágil (alguns de seus críticos, dizem que em certas situações isso não é bom).

Outra visão para a comparação entre as diversas abordagens para o processo de desenvolvimento: nível de iteratividade.

Como já vimos em cascata (método tradicional) e o iterativo (RUP), sendo este último mais natural, em função da complexidade do processo de desenvolver software.

O uso consciente do método em cascata é raro, em poucas ocasiões podemos ter num sistema a desenvolver, os requisitos definidos de forma completa no início do processo.

As possibilidades existentes: métodos baseados no RUP ou os métodos ágeis (XP, Scrum).

Processo de Desenvolvimento de Sw

Sistema de

Sw

Elipse: Sistema de Sw<!–[if mso & !supportInlineShapes & supportFields]> SHAPE \* MERGEFORMAT <![endif]–>

Requisitos

Do Usuário

<!–[if mso & !supportInlineShapes & supportFields]> <![endif]–>Quem

O que

Como

Quando

Visão geral do processo de desenvolvimento de sistemas baseado no padrão do RUP (Rational Unified Process), que se tornou a referência para o padrão geral da OMG.

SPEM (Software Process Engineering Metamodel) padrão sobre o processo de desenvolvimento de software, hoje assumido pela OMG, a mesma instituição que definiu a UML. Da mesma forma que a UML o padrão existente na OMG surgiu de um produto da empresa Rational, que foi comprada pela IBM já há algum tempo, esta transferiu o framework do RUP para uma fundação independente e o seu novo produto na área, o Rational Method Composer utliliza-o.

O RUP, como ainda é chamado, esse produto da IBM, é um software customizável de apoio ao processo de desenvolvimento de sistemas.

Visão Geral

Desenvolvimento iterativo

Administração de requisitos

Geração de software com arquitetura baseada em componentes ou serviços

Utilização de modelos visuais

Verificação contínua de qualidade

Gerenciamento de Mudanças

Framework (estrutura) genérica

Pode ser adaptado para diferentes classes de:

Sistemas de software

Áreas de aplicação

Tipos de organização

Níveis de competência

Tamanhos de projeto

Apesar de ser adaptável o RUP às necessidades de sua empresa muitos ainda o acham muito pesado ($ preço), difícil de ser usado. Essa visão é reforçada pela tendência do uso abordagens ágil.

Algumas características

Baseado em casos de uso

Centrado em arquitetura

Iterativo

Incremental

Customizável

Usa UML

4 P’s do projeto

Um projeto de desenvolvimento em qualquer área visa um produto, através de um processo (conjunto encadeado de atividades, leva a construção de artefatos) nos quais os seus participantes assumem papéis específicos.

O RUP além de automatizar o desenvolvimento de projetos na área de software (é uma ferramenta para os engenheiros de software) tornou-se um padrão.

Ciclo de Vida de Sw

Os sistemas nas organizações são dinâmicos, passam por ciclos durante a toda sua vida. As mudanças que ocorrem, a sua deteriorização fazem com que, com o tempo, as necessidades de seus usuários não sejam mais satisfeitas, fazendo com que a organização invista em um novo projeto de desenvolvimento ou manutenção para vencer mais um ciclo da vida do sistema.

Cada ciclo de vida do software ocorre através de fases (Iniciação, Elaboração, Construção e Transição) e é concluído com um release (Conjunto relativamente completo e consistente de artefatos, prontos para serem executados) do sistema.

Para o processo de desenvolvimento de um software o RUP define um conjunto padronizado de fases. Os diversos ciclos da vida de um sistema caracterizam os vários releases do mesmo (os artefatos produzidos durante o tempo).

Fases, Marcos e Releases

Marco ( Milestones ) – Ponto onde os gerentes tomam decisões de negócios importantes: Continuar / Não continuar, Cronograma, Orçamento, Necessidades do projeto, Sincronismo do projeto. Aqui se encontram os aspectos técnicos e gerenciais.

O término de uma fase, do ponto de vista da gerência do projeto, é sinalizado por um marco (conjunto de artefatos padronizados). Os artefatos técnicos e relatórios gerenciais do marco permitem as definições necessárias quanto à continuidade ou não do projeto. Toda fase tem seu marco correspondente.

FaseIntervalo de tempo entre dois marcos de um processo de desenvolvimento de software.

Mediante tudo isso, o RUP pressupõe que o desenvolvimento seja iterativo, existindo a necessidade de sempre voltar atrás, para que algo seja refeito. Na medida em que o processo caminha releases do software vão sendo obtidos de forma iterativa. Ter somente um release pode custar caro ao fim do processo de desenvolvimento.

Assim no mundo de hoje, desenvolver software é mais um processo experimental (isso é uma verdade em sistemas complexos, envolvendo redes sociais, com pessoas espalhadas por todo o planeta).

Fase

Objetivos Principais

Critérios para avaliação do marco

Observações

Iniciação

Estabelecer: o escopo do projeto,

: o ambiente de suporte para o projeto ( hardware e software )

Definir: os critérios de aceite do projeto,

: as características do sistema, e selecionar aquelas que são críticas,

: riscos potenciais do projeto,

Estimar os custos e fazer o cronograma de todo o projeto,

Os envolvidos: aprovam a definição do escopo do projeto,

: concordam com os critérios de aceite do projeto;

: entendem e concordam com os requisitos dos sistemas que foram levantados;

: concordam com o orçamento e o cronograma do projeto,

Definição de uma estratégia para tratamento dos riscos do projeto,

O ambiente de suporte do projeto está disponível

Este processo possui uma estrutura estática.

QUEM – *Papéis (roles ), Funções e responsabilidades que podem ser designados a uma pessoa ou a uma equipe, necessitando de habilidades para realizar certa atividade e desenvolver certo artefato, Não são indivíduos

Chapéu que uma pessoa deve usar durante o processo

Uma pessoa pode usar um ou mais chapéus durante o desenvolvimento

COMO – Atividades (Unidade de trabalho tangível realizada através de um papel numa disciplina que **:

)

O QUÊ – Artefatos (Um conjunto tangível de informação que:***)

QUANDO – Marcos ( milestones) Disciplinas

* O RUP define para cada um desses papéis (analistas, desenvolvedores, testadores, gerentes, Outros Papéis) a sua responsabilidade na realização dos artefatos necessário e seu envolvimento nas diversas atividades de desenvolvimento, nas diversas fases do processo.

** Implica uma responsabilidade bem definida do papel exercido por alguém,

Leva a um resultado bem definido (artefatos ), baseada em entradas bem definidas ( artefatos ),

Representa uma unidade de trabalho com limites bem definidos,

Usada no planejamento do projeto e na designação de papéis.

Podem ser definidas em níveis diferentes (geral ou detalhado), usadas quando necessárias e permitem a definição de responsabilidades no processo de desenvolvimento de um projeto. Como essa atividade se insere nas fases do desenvolvimento, quem é o responsável por ela, quais os artefatos envolvidos.

Características

Granularidade diferente: podem durar horas ou dias,

Podem ser repetidas várias vezes em diversas iterações,

Podem ser feitas através de um ou mais papéis.

São compostas de passos (steps).

Categorias de passos:

A) De pensamento ——- Formulação

B) De realização ——- Criação / atualização de artefatos

C) De revisão ——- Inspeção de resultados de acordo com algum critério

Atividades complexas – divididas em passos de diversos tipos (sub-atividades). Para sistemas maiores o processo pode ser acompanhado pelos seus passos (em maior detalhe), sistemas com menos complexidade podem ser acompanhados pela atividade mais geral (com menos detalhes).

Passos

Categorias

Localizar atores

A

Localizar casos de uso

A

Descrever como interagem atores e casos de uso

A

Empacotar casos de uso e atores

B

Apresentar o modelo de casos de uso

B

Rever o modelo de casos de uso

C

Avaliar o resultado

C

O RUP tem características de tutorial, se você não sabe como fazer uma atividade, ele descreve todos os seus passos, os papéis envolvidos e os artefatos a serem desenvolvidos.

*** É criado, usado, modificado através dos papéis que as pessoas assumem,

Representa uma área de responsabilidade,

É controlado por versões.

Podendo ser compostos de outros artefatos.

Possíveis formas:

Modelo – Diagrama UML (modelo de casos de uso)

Elemento de um modelo (classe)

Documento (relatório da arquitetura do software )

Código fonte

Executáveis

Plano de projeto

Podem ser modelos, diagramas técnicos, relatórios gerenciais, componentes de software, o próprio software no seu todo.

Disciplinas do RUP

Área

Disciplinas

Engenharia

Modelagem de negócios

Requisitos

Análise e Design

Implementação

Teste

Implantação

Suporte

Gerenciamento de configuração e mudança

Gerenciamento do projeto

Ambiente

Disciplinas – Conjunto de atividades que envolvem as várias fases e são agrupados de acordo com a sua especificidade dentro da área de desenvolvimento de software ( por exemplo modelagem de processos de negócio).

As disciplinas visão técnica do processo, as fases visão gerencial.

Seqüência de atividades logicamente integradas que produzem um resultado de valor observável que tem a ver com os objetivos principais do projeto de desenvolvimento de software, descritas através do detalhamento do fluxo de trabalho (workflow ).

Para ambientes de desenvolvimento (sistemas) maiores e mais complexos existem profissionais especializados nessas disciplinas em função dos papéis necessários na mesma.

As disciplinas são descritas pelos fluxos de trabalho (workflow) que devem ocorrer em cada fase do RUP. Nesses fluxos de trabalho podemos ver em detalhe o encadeamento das atividades necessárias, os papéis envolvidos e os artefatos de entrada e os de saída.

Descrição do Processo – Estrutura Dinâmica

Cada fase é dividida em Iterações: conjunto distinto de atividades realizadas de acordo com um plano e critérios de avaliação, que resulta num release do software.

As atividades do fluxo de trabalho podem ser executadas várias vezes, em níveis de detalhe diferentes e de forma iterativa (visão dinâmica), obtendo-se vários releases durante o processo de desenvolvimento.

O RUP segue um processo de desenvolvimento iterativo (em espiral), em que você volta nas mesmas fases anteriores de forma crescente (com mais detalhe), refazendo aquilo que seja necessário.

Comparando processos de Sw

É importante saber em cada situação qual é a melhor abordagem a utilizar.

Cascata

Riscos pequenos

Sequencial

Integração e testes posteriores

Pouca Cerimônia

Muita Cerimônia

Documentação mínima

Documentação adequada

Processo leve

Rastreabilidade

Controle de mudanças

RUP Leve, XP Scrum

Iterativo

RUP Mèdio

Guiado pelo risco

RUP Pesado

Integração e testes contínuos

Para se comparar processos de desenvolvimento de software tem-se algumas visões: o nível de cerimônia exigido pelo mesmo. Esta pode ser medida pelo nível de detalhes usado, a formalização dos artefatos e papéis envolvidos, o controle exercido no processo. Processos mais complexos, que exigem maior qualidade, tendem a exigir no seu envolvimento maior cerimônia.

O RUP apresenta uma imagem de ser um processo cerimonioso, apesar de que a IBM tenta vender a idéia que o mesmo possa ser customizado, em níveis diferentes de cerimônia, em função das suas necessidades. Em contra partida o XP é um processo com pouca cerimônia, ágil (alguns de seus críticos, dizem que em certas situações isso não é bom).

Outra visão para a comparação entre as diversas abordagens para o processo de desenvolvimento: nível de iteratividade.

Como já vimos em cascata (método tradicional) e o iterativo (RUP), sendo este último mais natural, em função da complexidade do processo de desenvolver software.

O uso consciente do método em cascata é raro, em poucas ocasiões podemos ter num sistema a desenvolver, os requisitos definidos de forma completa no início do processo.

As possibilidades existentes: métodos baseados no RUP ou os métodos ágeis (XP, Scrum).

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: