Por: André Luiz de Paula Leite
IBTA: Engenharia de Software SOA – 09
Disciplina: RUP
Professor: Gustavo Grilo
Data: 29/11/2008
Introdução
A terceirização do desenvolvimento de software vem mudando a forma de se fazer tecnologia nesses últimos anos e com um crescendo constantemente. Com objetivos de reduzir custos, melhorar o nível dos serviços prestados com uma maior produtividade e especialização, as empresas vêm adotando essa pratica ao invés da contratação dos profissionais em regime CLT e desenvolvimento interno. Isso pode ser uma boa vantagem competitiva mais é preciso muito cuidado.
As empresas contratam consultorias especializadas em uma determinada tecnologia ou serviço, que disponibiliza profissionais para serem alocado internamento ou desenvolvem o produto em uma fabrica de software. Alguns aspectos serão levantados como as vantagens e desvantagens de adotar essas práticas exemplos de empresas que aderiram ou não.
A terceirização não deve ser vista somente como redução de custos, mas como alternativa para o controle de custos, tão pouco ela deve ser vista como uma forma de se livrar de um problema. Há alguns fatores que são motivadores para a terceirização. O primeiro é o econômico, mas só isso não basta, é preciso que haja a combinação de outros fatores, como a qualidade dos serviços, a confiabilidade do parceiro e a abrangência. Mas nem sempre terceirizar é uma decisão fácil. Já o que é “core business” (negócio principal) não deve ser terceirizado, mantendo o controle do negócio, terceirizando apenas a mão de obra qualificada.
É preciso ter certeza de que o fornecedor possui escala para atender adequadamente as necessidades, em questões de quantidade de mão de obra, qualidade, tecnologia adequada, comprometimento, conhecimento do negócio e flexibilidade nos contratos.
Muitas empresas como o grupo JBS, líder no mercado de alimentos do Brasil e maior exportador de carnes do mundo, acredita que terceirizando serviços de software se tem menos comprometimento e deficiência na análise de negócio da empresa, eles mantêm uma equipe de 30 programadores contratados como CLT para o desenvolvimento do ERP interno, sistemas web e BI. Quando a JBS necessita de um profissional para um serviço específico e temporário, recorre à terceirização por um período de três meses no máximo.
Os grandes bancos nacionais tendem a ser mais seletivos, terceirizando atividades que apresentem menos riscos. Segundo estudos feitos internamente, chegaram à conclusão que a economia com a terceirização de softwares seria entre 15% a 20%, muito pouco em comparação aos riscos que iriam correr. Ainda falta muita maturidade aos grandes fornecedores, conta um CIO.
A Nasscom (associação nacional de empresas de software e serviços), afirma que as empresas de terceirização da Índia já estão enfrentando aumento nos custos, incluindo a mão-de-obra, além da competição de empresas de serviços mundiais que estão construindo centros na Índia. Os grandes grupos multinacionais perceberam que a redução de custos pode ser conseguida no próprio Brasil, com uma série de vantagens: menor diferença de fuso horário, proximidade do modelo de negócios e qualidade superior à dos produtos indianos. O Brasil também tem se saído bem em relação aos concorrentes latino-americanos porque tem um atrativo a mais – um gigantesco mercado interno.
Vantagens da terceirização de softwares:
Terceirizar o desenvolvimento e manutenção de um software geralmente custa menos do que desenvolver internamento, ter uma equipe interna qualificada para cada tipo de projeto é muito custoso, hoje o tipo de contratação CLT se paga muito imposto e custos adicionais, treinamentos de tecnologias novas ou algo específico como dispositivos móveis.
O desenvolvimento em uma fabrica pode ser mais rápido utilizando um processo ágil como o scrum ou mais completo como o RUP, reaproveitamento da experiência com outros clientes do mesmo segmento e bibliotecas de código reutilizáveis.
Para um cliente é mais cômodo exigir um nível de qualidade da fabrica de software e a entrega do produto no prazo determinado, caso contrário muitas vezes é recorrido a justiça.
Desvantagens da terceirização de softwares:
Falta de comprometimento dos profissionais que atuam nas consultorias e fabricas de software com a empresa contratada, pois eles não vivem os valores no seu dia a dia. Geralmente são profissionais contratados como pessoa jurídica ou cooperados que podem a qualquer momento mudar de emprego e projeto.
Dificuldade da consultoria de entender e absorver o negócio e processos internos de seus clientes, devido à má comunicação entre funcionários e terceiros, os próprios funcionários não sabem explicar os problemas ou acham que documentação e analise não são necessários.
O mundo atual dos negócios apresenta uma característica clara: a constante necessidade de mudança. Neste contexto, é fundamental que os contratos de terceirização reflitam esta característica e, portanto, tenham a necessária flexibilidade para acomodar as inevitáveis mudanças nas necessidades dos negócios.
A falta de confiabilidade ao fornecer informações da empresa que irão ser entregues a empresas terceiras como o banco de dados, relatórios e documentos e a dificuldade de garantir a qualidade do código desenvolvido.
Conclusão:
As empresas de todos os segmentos estão adotando as parcerias com especialistas para gerir a sua área de Tecnologia da Informação. Hoje, a maioria das grandes companhias tem algum processo terceirizado.
Essa tendência pode proporcionar resultados positivos ou descontentamento para as empresas e profissionais, antes de adotar uma decisão é preciso fazer uma analise comparando as vantagens de desvantagens e o impacto que isso causará adotar as melhores praticam na escolha de parceiros adequados e medir o nível do resultado obtido.
Referências:
A terceirização e o desenvolvimento de sistemas de informação numa empresa recém privatizada.
Raquel Oliveira Xavier (PROPAD/UFPE)
José Rodrigues Filho (PROPAD/UFPE)
07/02/ 2008 – O que mudar para melhorar a terceirização de serviços de TI
Presidente da Booz Allen Hamilton do Brasil. Líder da Prática de Indústrias, América do Sul.
http://computerworld.uol.com.br/gestao/leticia_costa/idgcoluna.2008-01-07.6837298613/
11/08 2008 - Focando em software, Indianas querem US$ 12 bilhões até 2015
IDG News Service
http://computerworld.uol.com.br/terceirizacao/2008/08/11/indianas-focam-em-software-e-preveem-receita-de-us-12-bi-ate-2015/
22/06/2007 – Vantagens do Outsourcing em TI
Miguel Ruiz
http://imasters.uol.com.br/artigo/6428/gerencia/vantagens_do_outsourcing_em_ti/
04 /04 /2006 - Terceirização de TI é realidade para 42% das empresas
COMPUTERWORLD
http://computerworld.uol.com.br/terceirizacao/2006/05/04/idgnoticia.2006-05-04.8399935439/
18/01/2006 - A Índia é aqui
Cristiane Barbieri
http://www.terra.com.br/istoedinheiro/435/ecommerce/india_aqui.htm
14/07/2008 - Até pequenos negócios aderem à terceirização
Valor Econômico
http://www.sebrae-sc.com.br/newart/default.asp?materia=16113
15/07/2008 - Terceirizar é uma boa opção?
Carlos Ossamu , da Info CORPORATE
http://info.abril.com.br/corporate/outsourcing/terceirizar-e-uma-boa-opcao.shtml
sábado, 20 de dezembro de 2008
sexta-feira, 19 de dezembro de 2008
Documento Arquitetural
Segue o link do documento arquitetural que é desenvolvido na fase de elaboração do RUP, é apenas um modelo simples acadêmico e pode ajudar como auxilio. IBTA – Pós Graduação Disciplina: Arquitetura de Software Professor: Wellington R. Pinheiro Alunos: Fabio de Aguiar Silva e André Luiz de Paula Leite
LINK
LINK
UML, RUP e o framework Zachman: melhores juntos
Estou publicando essa dissertação referente a um artigo sobre os temas UML, RUP e framework Zachman.
PÓS GRADUAÇÃO IBTA
ENGENHARIA DE SOFTWARE BASEADA EM SOA
Módulo RUP
UML, RUP e o framework Zachman: melhores juntos
André Luiz de Paula Leite
Charles Pereira Mendes
Fábio Aguiar
Juliana Ferreira
12/12/2008
São Paulo, SP
ÍNDICE
1 - Conhecendo UML, RUP e Zachman.. 3
2 - Zachman durante o tailoring do RUP.. 4
3 - Ao término do projeto RUP utilize o Zachman.. 4
4 - Observe a estrutura Zachman, durante o planejamento do RUP.. 5
5 - Utilize RUP com Zachman para auxiliar a empresa. 7
1 - Conhecendo UML, RUP e Zachman
Os três sistemas em discussão foram criados para necessidades específicas, porém eles podem ser compartilhados e utilizados em conjunto, de forma que um supra a necessidade do outro.
O RUP utiliza a UML como linguagem de modelagem padrão. O framework Zachman não estabelece o uso de uma notação específica, porém não impede o uso de uma. Sendo assim, o uso da UML como notação padrão entre os frameworks torna se uma alternativa interessante.
Situações em que cada uma dessas tecnologias pode ser aproveitada são diferentes. Por exemplo, utilizar o RUP para um projeto de arquitetura empresarial não seria justificável, assim como o uso do framework Zachman em ambiente de desenvolvimento não faria nenhum sentido.
As duas definições de ciclo de projeto são semelhantes, o que é justificado pelo fato de que tanto o RUP quanto o Zachman framework serem dirigidos por artefatos que herdam suas estruturas do principio de design de arquitetura centralizada.
Essas semelhanças implicam que as duas tecnologias podem se enriquecer mutuamente, dado a crescente complexidade dos sistemas empresariais e dos projetos das empresas.
Sendo assim, existem alguns pontos onde as metodologias em questão podem completar entre si:
- Considerar a UML como Notação comum
O framework Zachman não utiliza uma notação padrão, enquanto o RUP adota a UML como padrão dos seus documentos. Para que não ocorra o uso de varias notações em que cada projeto utilize uma e prejudique o entendimento, torna se interessante o uso da UML nos projetos RUP e nos que utilizarem o Zackman framework. Dessa forma teremos uma notação fundamentada para uso nos dois frameworks.
- Utilizar a UML para conectar o RUP e o Zackman framework
O uso da UML, além de trazer as vantagens de ser uma ótima linguagem para análise e design, pode ser o gatilho para a utilização do RUP ou do Zackman Framework. Se o uso da UML já esta sólida na empresa, fica melhor a utilização no Zackman.
- Aprender RUP através do Zackman pode ser mais fácil.
A aprendizagem do RUP implica em compreender toda sua estrutura e princípios que servem para orientar o projeto. Sendo assim, a melhor maneira de aprender o RUP é através da experiência de projeto.
Uma abordagem desse tipo ajuda a ganhar apreço pelo framework Zachman, pois muitos aspectos dele têm paralelos com as práticas do RUP.
Compreender o framework Zachman é mais fácil do que a compreensão do RUP, pois lida com a visão estática da arquitetura empresarial e não com modelos e processos. No entanto, o caminho de aprendizagem do framework Zachman pode beneficiar a aplicação de alguns princípios fundamentais do RUP como “dirigido por requisitos”, “centrado em arquitetura” e “iterativo”. A sensação do autor do artigo é que o Zachman framework torna mais fácil o percebimento de como esses princípios podem infundir no processo de aprendizagem e sua aplicação prática.
2 - Zachman durante o tailoring do RUP
Durante a fase de tailoring do RUP, são realizadas perguntas em relação aos envolvidos. Como por exemplo, questionar neste processo, o responsável por modelar a arquitetura do projeto, quem faz a modelagem de processos acontecer, qual técnica deveria ser usada para a utilização da modelagem e como as responsabilidades deverão ser divididas baseando-se no nível de detalhe. Diante a estas questões, o framework Zachman pode ter respostas corretas para elas.
Um arquiteto de processos deverá identificar o baseline da arquitetura da empresa, caso a empresa escolha a arquitetura Zachman, esta irá guiar a análise/planejamento de acordo com a ênfase em um determinado artefato.
3 - Ao término do projeto RUP utilize o Zachman
A disciplina de arquitetura da empresa não está definida no ciclo de vida do RUP, logo que não há um guia de modelos de arquitetura voltados para a empresa.
Para esta limitação, o modelo de Zachman poderá ser utilizado pelos arquitetos do projeto. Este modelo funciona como um framework organizacional, onde todos os envolvidos interagem no projeto. O Zachman juntará em células, as atividades e fases do RUP de forma dinâmica, sendo possível navegar facilmente pelos artefatos. Após a conclusão de um projeto RUP, a estrutura Zachman poderá ser convertida em arquivos e separada por pastas, onde a organização poderá reutilizar para outros projetos.
4 - Observe a estrutura Zachman, durante o planejamento do RUP
A arquitetura do framework Zachman pode apresentar vantagens e desvantagens.
Vantagens
Desvantagens
É fácil de entender, aborda a empresa como um todo, ela é definida independentemente de instrumentos ou metodologias, e quaisquer questões que possam ser mapeadas contra a compreender onde estão inseridos.
Uma importante desvantagem é o grande número de células, que é um obstáculo para a aplicabilidade prática do quadro. Também as relações entre as células que não são bem especificadas.
A arquitetura do framework Zachman, é composta por perguntas (ver figura 1):
§ What (O Quê - Dados),
§ How (Como - Função),
§ Where (Onde – Rede),
§ Who (Quem – Pessoas),
§ When (Quando – Tempo),
§ Why (Por que – Motivação).
Figura 1. Arquitetura Zachman.
De qualquer forma, aplicar a arquitetura Zachman em uma organização pode ser complicada para arquitetos menos experientes. Já para arquitetos mais experientes, a sua aplicação pode correr de uma forma mais prática, sem gerar dúvidas e confusões. O fato é que, aplicando esta arquitetura corretamente, no final das contas, sua aplicação irá se revelar muito útil tanto para o projeto quanto para a organização.
5 - Utilize RUP com Zachman para auxiliar a empresa
É muito importante as empresas estarem realizando uma prova de conceitos da arquitetura dos projetos de software a serem desenvolvidos, onde muitas vezes é negligenciada por terem em mente uma solução otimista ou não dar importância.
Cada vez mais, os projetos de desenvolvimento de sistemas estão sendo feitos com um custo e prazo menor do real e isso faz com que seja diminuído o tempo de especificação dos requisitos e arquitetura. Devemos levar em consideração a falta de profissionais qualificados que entendam de modelo de processo de desenvolvimento de software.
Hoje as empresas estão começando a entender essa necessidade e estão introduzindo práticas em seus projetos, ajudando a gerenciar e diminuir os riscos logo nas fases iniciais do projeto, ajudando na comunicação e interação entre as equipes.
Podem-se combinar essas práticas com os casos de uso desenvolvidos no RUP, tendo uma visão geral do processo em todas as fases do ciclo de vida do projeto.
PÓS GRADUAÇÃO IBTA
ENGENHARIA DE SOFTWARE BASEADA EM SOA
Módulo RUP
UML, RUP e o framework Zachman: melhores juntos
André Luiz de Paula Leite
Charles Pereira Mendes
Fábio Aguiar
Juliana Ferreira
12/12/2008
São Paulo, SP
ÍNDICE
1 - Conhecendo UML, RUP e Zachman.. 3
2 - Zachman durante o tailoring do RUP.. 4
3 - Ao término do projeto RUP utilize o Zachman.. 4
4 - Observe a estrutura Zachman, durante o planejamento do RUP.. 5
5 - Utilize RUP com Zachman para auxiliar a empresa. 7
1 - Conhecendo UML, RUP e Zachman
Os três sistemas em discussão foram criados para necessidades específicas, porém eles podem ser compartilhados e utilizados em conjunto, de forma que um supra a necessidade do outro.
O RUP utiliza a UML como linguagem de modelagem padrão. O framework Zachman não estabelece o uso de uma notação específica, porém não impede o uso de uma. Sendo assim, o uso da UML como notação padrão entre os frameworks torna se uma alternativa interessante.
Situações em que cada uma dessas tecnologias pode ser aproveitada são diferentes. Por exemplo, utilizar o RUP para um projeto de arquitetura empresarial não seria justificável, assim como o uso do framework Zachman em ambiente de desenvolvimento não faria nenhum sentido.
As duas definições de ciclo de projeto são semelhantes, o que é justificado pelo fato de que tanto o RUP quanto o Zachman framework serem dirigidos por artefatos que herdam suas estruturas do principio de design de arquitetura centralizada.
Essas semelhanças implicam que as duas tecnologias podem se enriquecer mutuamente, dado a crescente complexidade dos sistemas empresariais e dos projetos das empresas.
Sendo assim, existem alguns pontos onde as metodologias em questão podem completar entre si:
- Considerar a UML como Notação comum
O framework Zachman não utiliza uma notação padrão, enquanto o RUP adota a UML como padrão dos seus documentos. Para que não ocorra o uso de varias notações em que cada projeto utilize uma e prejudique o entendimento, torna se interessante o uso da UML nos projetos RUP e nos que utilizarem o Zackman framework. Dessa forma teremos uma notação fundamentada para uso nos dois frameworks.
- Utilizar a UML para conectar o RUP e o Zackman framework
O uso da UML, além de trazer as vantagens de ser uma ótima linguagem para análise e design, pode ser o gatilho para a utilização do RUP ou do Zackman Framework. Se o uso da UML já esta sólida na empresa, fica melhor a utilização no Zackman.
- Aprender RUP através do Zackman pode ser mais fácil.
A aprendizagem do RUP implica em compreender toda sua estrutura e princípios que servem para orientar o projeto. Sendo assim, a melhor maneira de aprender o RUP é através da experiência de projeto.
Uma abordagem desse tipo ajuda a ganhar apreço pelo framework Zachman, pois muitos aspectos dele têm paralelos com as práticas do RUP.
Compreender o framework Zachman é mais fácil do que a compreensão do RUP, pois lida com a visão estática da arquitetura empresarial e não com modelos e processos. No entanto, o caminho de aprendizagem do framework Zachman pode beneficiar a aplicação de alguns princípios fundamentais do RUP como “dirigido por requisitos”, “centrado em arquitetura” e “iterativo”. A sensação do autor do artigo é que o Zachman framework torna mais fácil o percebimento de como esses princípios podem infundir no processo de aprendizagem e sua aplicação prática.
2 - Zachman durante o tailoring do RUP
Durante a fase de tailoring do RUP, são realizadas perguntas em relação aos envolvidos. Como por exemplo, questionar neste processo, o responsável por modelar a arquitetura do projeto, quem faz a modelagem de processos acontecer, qual técnica deveria ser usada para a utilização da modelagem e como as responsabilidades deverão ser divididas baseando-se no nível de detalhe. Diante a estas questões, o framework Zachman pode ter respostas corretas para elas.
Um arquiteto de processos deverá identificar o baseline da arquitetura da empresa, caso a empresa escolha a arquitetura Zachman, esta irá guiar a análise/planejamento de acordo com a ênfase em um determinado artefato.
3 - Ao término do projeto RUP utilize o Zachman
A disciplina de arquitetura da empresa não está definida no ciclo de vida do RUP, logo que não há um guia de modelos de arquitetura voltados para a empresa.
Para esta limitação, o modelo de Zachman poderá ser utilizado pelos arquitetos do projeto. Este modelo funciona como um framework organizacional, onde todos os envolvidos interagem no projeto. O Zachman juntará em células, as atividades e fases do RUP de forma dinâmica, sendo possível navegar facilmente pelos artefatos. Após a conclusão de um projeto RUP, a estrutura Zachman poderá ser convertida em arquivos e separada por pastas, onde a organização poderá reutilizar para outros projetos.
4 - Observe a estrutura Zachman, durante o planejamento do RUP
A arquitetura do framework Zachman pode apresentar vantagens e desvantagens.
Vantagens
Desvantagens
É fácil de entender, aborda a empresa como um todo, ela é definida independentemente de instrumentos ou metodologias, e quaisquer questões que possam ser mapeadas contra a compreender onde estão inseridos.
Uma importante desvantagem é o grande número de células, que é um obstáculo para a aplicabilidade prática do quadro. Também as relações entre as células que não são bem especificadas.
A arquitetura do framework Zachman, é composta por perguntas (ver figura 1):
§ What (O Quê - Dados),
§ How (Como - Função),
§ Where (Onde – Rede),
§ Who (Quem – Pessoas),
§ When (Quando – Tempo),
§ Why (Por que – Motivação).
Figura 1. Arquitetura Zachman.
De qualquer forma, aplicar a arquitetura Zachman em uma organização pode ser complicada para arquitetos menos experientes. Já para arquitetos mais experientes, a sua aplicação pode correr de uma forma mais prática, sem gerar dúvidas e confusões. O fato é que, aplicando esta arquitetura corretamente, no final das contas, sua aplicação irá se revelar muito útil tanto para o projeto quanto para a organização.
5 - Utilize RUP com Zachman para auxiliar a empresa
É muito importante as empresas estarem realizando uma prova de conceitos da arquitetura dos projetos de software a serem desenvolvidos, onde muitas vezes é negligenciada por terem em mente uma solução otimista ou não dar importância.
Cada vez mais, os projetos de desenvolvimento de sistemas estão sendo feitos com um custo e prazo menor do real e isso faz com que seja diminuído o tempo de especificação dos requisitos e arquitetura. Devemos levar em consideração a falta de profissionais qualificados que entendam de modelo de processo de desenvolvimento de software.
Hoje as empresas estão começando a entender essa necessidade e estão introduzindo práticas em seus projetos, ajudando a gerenciar e diminuir os riscos logo nas fases iniciais do projeto, ajudando na comunicação e interação entre as equipes.
Podem-se combinar essas práticas com os casos de uso desenvolvidos no RUP, tendo uma visão geral do processo em todas as fases do ciclo de vida do projeto.
quinta-feira, 18 de dezembro de 2008
Proposta de implantação RUP
Estou postando uma proposta que o meu grupo da pós em Engenharia de Software SOA na disciplina RUP desenvolveu conforme um case real para a implantação de uma metodologia de processos de software.
Introdução
O Rational Unified Process ou RUP é um farmework de processo de desenvolvimento de software completo desenvolvido pela Rational Software. Trata-se de uma metodologia de desenvolvimento iterativa que pode ser descrita como dirigida por casos de uso, riscos e arquitetura. Para muitos desenvolvedores que começam a usar o RUP são conceitos completamente novos, e isto significa que é necessário muito treinamento em projetos onde o RUP é utilizado pela primeira vez. Apenas “apenas ler o livro” não é o bastante.
Este trabalho visa descrever uma proposta de implementação do RUP para a empresa SISC e as vantagens da utilização desse processo definido e projeção de uma melhora na maturidade do processo de desenvolvimento de software e das equipes de desenvolvimento.
SISC
Sediada em uma pequena cidade do sudoeste de Santa Catarina, a SISC é uma empresa de desenvolvimento de software com grande influência na região onde se situa. Com uma carteira de cerca de 500 clientes distribuídos pelo Brasil e Argentina, a SISC possui como carro-chefe um ERP especializado em atacadistas, o SISC Enterprise, responsável por mais de 90% de seu faturamento.
A SISC começou com uma estrutura familiar de administração, porém hoje possui apenas o seu diretor executivo como sócio da empresa e conta com uma administração profissional e funcionários contratados sob o regime CLT.
A equipe da SISC está toda situada em um mesmo local, três andares de um prédio comercial na principal rua da cidade. Os escritórios fora de Dois Irmãos contam apenas com equipes de vendas e alguns técnicos de pré-venda que vez ou outra fazem papel de suporte local aos clientes mais importantes. A equipe de desenvolvimento é dividida pelos módulos, sendo que cada módulo tem um grupo especializado nele
O Contexto de Melhoria de Processos de Software na SISC
A melhoria de processo de software é sempre feita sob um contexto de negócio. Tendo em vista que desenvolvimento de software é a área chave na SISC a implementação de um novo processo deve ser colocado como uma grande evolução nessa área da empresa.
O processo atual de desenvolvimento de software da SISC é iniciado geralmente por um chamado ou uma melhoria solicitada pelo cliente. Essa solicitação é atendida no seu primeiro estágio pela equipe de Análise, que dá início ao preenchimento do PESw, documento base para o acompanhamento do desenvolvimento dos requisitos até o teste final que precede a entrega. A equipe de Análise identifica o módulo afetado e encaminha o PESw ao gerente para aprovação e posteriormente para o cliente para o aceite, após isso são extraídos os casos de uso macro e feito pré-estimativas para ser encaminhado ao arquiteto do módulo. Após isto o arquiteto valida a estimativa apresentada junto ao gerente para que seja passado para a fase de implementação. Em alguns casos o arquiteto de testes produz nessa fase os artefatos para a fase de testes, porém na prática algumas vezes isto acontece junto com a fase de implementação.
Segundo o gerente de desenvolvimento, esse processo funciona bem, salvo quando há trocas de prioridade ou prazos muito apertados. A SISC começa a orientar seu processo visando melhorar a qualidade do seu software, pois já possui dois arquitetos de testes que fazem parte da equipe de Análise, e dois recursos trabalhando na automação dos testes, porém são atividades que iniciaram há pouco tempo e não funcionam como esperado.
Não foi detectada uma forma bem definida para as métricas de estimativas utilizadas, o que pode levar aos problemas com cronogramas apertados. Também não é visto um processo de modelagem detalhado para refinamento das especificações apresentadas no PESw, assim como a utilização de um padrão de projetos ou arquitetura única para o projeto. Outro ponto verificado é a ausência do controle de versões e entregas feitas, embora tenha sido descrito uma tentativa de uso de ferramenta de versionamento, tal experiência não foi produtiva por falta de um planejamento pra utilização da mesma no processo de desenvolvimento.
Desafios e Objetivos
A SISC tem um balanço bastante positivo, mas com as metas de expansão determinadas pelos sócios começa a esbarrar em alguns obstáculos devido ao seu crescimento pouco planejado e estruturado. A diretoria da SISC definiu alguns objetivos para a otimização de processos a ser implantada:
1. Tornar possível o reuso de requisitos;
2. Melhorar a qualidade do produto;
3. Melhorar a produtividade da equipe;
4. Aumentar a capacitação técnica da equipe;
5. Melhorar a forma como são feitos os testes;
6. Entregar quatro atualizações do SISC Enterprise por ano, com melhorias significativas no produto, além das correções de bugs
A conclusão é que a SISC precisa de um processo de desenvolvimento de software bem estruturado que atenda as necessidades de crescimento da empresa e melhoria da qualidade e ritmo de desenvolvimento do produto a fim de suprir os desafios e atingir os objetivos propostos.
Implementação de um novo processo de desenvolvimento
O Rational Unified Process é um processo de engenharia de software. Ele oferece uma abordagem baseada em disciplinas, que nada mais é do que uma coleção de atividades relacionadas a uma área de interesse principal, 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ível.
As disciplinas abordadas pelo RUP são: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação, Gerência de Mudança, Gerenciamento de Projeto e Ambiente, onde cada uma delas tem objetivos bem definidos que serão executados por pessoas no projeto com papéis atribuídos e tendo como produto artefatos previamente estabelecidos.
A base do RUP é que ele é dividido nas fases de Iniciação, Elaboração, Construção e Transição ao longo do tempo do projeto onde as disciplinas são distribuídas e irão evoluindo utilizando o conceito de iteração.
Neste documento não entraremos nos detalhes das fases, disciplinas e artefatos, sendo proposto um workshop para isso.
Para que se possa ter uma visão mais clara da interação entra as fases e as disciplinas do RUP, apresentamos o gráfico abaixo:
Podemos resumir que RUP é baseado em um conjunto de princípios de desenvolvimento de software e melhores práticas como por exemplo:
1. Desenvolvimento de software iterativo
2. Gerenciamento de requisitos
3. Uso de arquitetura baseada em componente
4. Modelagem visual de software
5. Controle de alteração no software
Analisando o processo atual da SISC, visando uma melhoria nos processos e mais qualidade no desenvolvimento de software propomos uma customização do RUP adequando às necessidades da empresa.
As disciplinas do RUP nos permitirão atacar de uma maneira objetiva os problemas detectados no processo de desenvolvimento e principais reclamações de clientes.
Para implantação do RUP, propomos que algumas disciplinas tenham mais ênfase do que outras. A escolha dessas disciplinas se dará devido à prioridade das necessidades da SISC.
· Modelagem de negócios: entender os problemas atuais da SISC e identificar as possibilidades de melhoria
· Requisitos: padronizar e documentar o levantamento de requisitos que já é realizado hoje
· Análise e Design: no momento não é necessária implementação desta disciplina pois o software já está desenvolvido. Porém para inclusão de mais módulos ou novos projetos ela deverá ser implementada.
· Teste: padronizar e documentar os procedimentos de testes.
· Implantação: no momento essa disciplina não será implementada pois não foram identificados problemas na implantação do software nos clientes.
· Gerência de Mudança: um dos problemas detectados foi em relação as customizações do software nos clientes e a difícil manutenção disso. Com esta disciplina este problema será solucionado permitindo a satisfação dos clientes finais, maior organização da SISC, maior aproveitamento do tempo devido a não ter mais retrabalhos e atingir a meta de liberação de mais builds por ano.
· Gerenciamento de Projeto: enfatizar os aspectos de um processo de desenvolvimento iterativo como gerenciamento de risco, planejamento de um processo iterativo e monitoramento do mesmo.
· Ambiente: é nesta disciplina que faremos a customização do RUP para a SISC.
Estratégia de implementação
Alterar o processo de desenvolvimento em uma empresa é uma tarefa árdua e possui diversos fatores críticos de sucesso, sendo que o mais importante deles é o comprometimento das partes envolvidas. É necessário que a diretoria entenda perfeitamente a extensão das mudanças feitas e que esta permeia por todo o departamento de desenvolvimento, por isso é de extrema importância que a diretoria participe ativamente principalmente na parte inicial onde serão definidos e refinados quais objetivos deverão ser alcançados e as expectativas para cada objetivo.
Sabemos que a simples apresentação de um processo não será suficiente pois este somente mostra o que fazer mas não como. Por isso propomos em conjunto com um projeto piloto serem feitos treinamentos nas ferramentas que serão selecionadas posteriormente para auxilio da metodologia junto com a definição do projeto piloto, integrando assim os conhecimentos das ferramentas com a metodologia e processo.
Mediante análise da empresa SISC, é notado que devido a sua complexidade é impossível implementar o RUP em todos os projetos pilotos de uma única vez. Por isso é proposta uma abordagem de implementação em fases. Serão definidos cerca de 3 projetos a ser usado como piloto para a implementação e adequação do RUP, tendo também como fim envolver outras partes do departamento de desenvolvimento onde também será construída uma base de profissionais treinados na metodologia que servirão de mentores para a disseminação do processo para o restante dos projetos.
O projeto piloto em si deve ter algumas características chave:
· Riscos técnicos gerenciáveis, o projeto não pode ser de altíssimo risco tendo em vista não colocar muita pressão sobre o mesmo prejudicando o processo de aprendizagem
· Prioridade alta, porem o projeto não pode ser de pouca importância para que não seja deixado de lado por qualquer outra prioridade e também a fim de utilizar o processo a ser implementado em projetos que sejam mais comuns no departamento de desenvolvimento
· Equipe comprometida, este é um ponto chave de sucesso pois para que o novo processo seja facilmente implementado é necessário que a equipe tenha interesse em aprender e não seja resistente a mudanças
· Cronograma realista, a data de entrega não pode ser critica pois é esperado que os projetos pilotos tenham uma produtividade menor nas fases iniciais dos primeiros projetos pois é necessário o tempo para aprender. Nós estimamos que seja necessário aproximadamente 4 semanas extra para aprendizagem do novo processo, ferramentas e métodos.
É provado que a melhor forma de aprendizagem é a combinação de teoria e prática, por isso propomos que alem de ser fornecido material de suporte, antes do início do projeto todos os envolvidos deverão passar por um workshop “RUP na SISC” para entender o que será alterado e por quê. Após isso um treinamento de 2 dias com os fundamentos do RUP para que seja iniciado o projeto piloto, então serão feitos treinamentos de metodologias e ferramentas respectivas à fase que o projeto piloto se encontra. Além disso um especialista deverá cuidar da parte de mentoring a fim de sanar eventuais dúvidas teóricas durante o processo de desenvolvimento do projeto e acompanhar o desenvolvimento do uso do novo processo.
Durante o projeto piloto serão apresentados avaliações dos resultados obtidos mostrando os pontos de melhora da produtividade e qualidade do software, além dos objetivos aqui apresentados que já foram alcançados. Depois de estabelecido um senso comum sobre qual a customização do processo que melhor se aplica a SISC e deixado isto bem definido é feita uma preparação do ambiente para a utilização desse processo nos outros projetos novos. Nesta fase os participantes dos projetos pilotos serão de grande importância para serem mentores e auxiliar na utilização do processo durante os novos projetos.
Resultados Esperados
Em longo prazo os efeitos esperados pelo uso de um novo processo de desenvolvimento são:
Requisitos de negócio bem definidos como entrada do processo
Melhor adequação as reais necessidades do cliente na hora da entrega
Menor tempo de entrega para as versões
Mais projetos entregues dentro do prazo e orçamento
Redução dos custos de re-trabalho
Melhor manutenção do produto
Um processo de desenvolvimento de aplicações comum
Acreditamos que seja possível uma grande melhora significativa nos resultados da empresa e qualidade do produto em curto-médio prazo, sendo que no prazo de 2 a 3 anos todos os objetivos aqui apresentados estejam completamente alcançados e possibilitando um controle bem maior sobre as solicitações dos diversos clientes possibilitando assim uma grande melhoria na qualidade de atendimento dos chamados como também uma fácil reutilização das customizações já feitas.
Introdução
O Rational Unified Process ou RUP é um farmework de processo de desenvolvimento de software completo desenvolvido pela Rational Software. Trata-se de uma metodologia de desenvolvimento iterativa que pode ser descrita como dirigida por casos de uso, riscos e arquitetura. Para muitos desenvolvedores que começam a usar o RUP são conceitos completamente novos, e isto significa que é necessário muito treinamento em projetos onde o RUP é utilizado pela primeira vez. Apenas “apenas ler o livro” não é o bastante.
Este trabalho visa descrever uma proposta de implementação do RUP para a empresa SISC e as vantagens da utilização desse processo definido e projeção de uma melhora na maturidade do processo de desenvolvimento de software e das equipes de desenvolvimento.
SISC
Sediada em uma pequena cidade do sudoeste de Santa Catarina, a SISC é uma empresa de desenvolvimento de software com grande influência na região onde se situa. Com uma carteira de cerca de 500 clientes distribuídos pelo Brasil e Argentina, a SISC possui como carro-chefe um ERP especializado em atacadistas, o SISC Enterprise, responsável por mais de 90% de seu faturamento.
A SISC começou com uma estrutura familiar de administração, porém hoje possui apenas o seu diretor executivo como sócio da empresa e conta com uma administração profissional e funcionários contratados sob o regime CLT.
A equipe da SISC está toda situada em um mesmo local, três andares de um prédio comercial na principal rua da cidade. Os escritórios fora de Dois Irmãos contam apenas com equipes de vendas e alguns técnicos de pré-venda que vez ou outra fazem papel de suporte local aos clientes mais importantes. A equipe de desenvolvimento é dividida pelos módulos, sendo que cada módulo tem um grupo especializado nele
O Contexto de Melhoria de Processos de Software na SISC
A melhoria de processo de software é sempre feita sob um contexto de negócio. Tendo em vista que desenvolvimento de software é a área chave na SISC a implementação de um novo processo deve ser colocado como uma grande evolução nessa área da empresa.
O processo atual de desenvolvimento de software da SISC é iniciado geralmente por um chamado ou uma melhoria solicitada pelo cliente. Essa solicitação é atendida no seu primeiro estágio pela equipe de Análise, que dá início ao preenchimento do PESw, documento base para o acompanhamento do desenvolvimento dos requisitos até o teste final que precede a entrega. A equipe de Análise identifica o módulo afetado e encaminha o PESw ao gerente para aprovação e posteriormente para o cliente para o aceite, após isso são extraídos os casos de uso macro e feito pré-estimativas para ser encaminhado ao arquiteto do módulo. Após isto o arquiteto valida a estimativa apresentada junto ao gerente para que seja passado para a fase de implementação. Em alguns casos o arquiteto de testes produz nessa fase os artefatos para a fase de testes, porém na prática algumas vezes isto acontece junto com a fase de implementação.
Segundo o gerente de desenvolvimento, esse processo funciona bem, salvo quando há trocas de prioridade ou prazos muito apertados. A SISC começa a orientar seu processo visando melhorar a qualidade do seu software, pois já possui dois arquitetos de testes que fazem parte da equipe de Análise, e dois recursos trabalhando na automação dos testes, porém são atividades que iniciaram há pouco tempo e não funcionam como esperado.
Não foi detectada uma forma bem definida para as métricas de estimativas utilizadas, o que pode levar aos problemas com cronogramas apertados. Também não é visto um processo de modelagem detalhado para refinamento das especificações apresentadas no PESw, assim como a utilização de um padrão de projetos ou arquitetura única para o projeto. Outro ponto verificado é a ausência do controle de versões e entregas feitas, embora tenha sido descrito uma tentativa de uso de ferramenta de versionamento, tal experiência não foi produtiva por falta de um planejamento pra utilização da mesma no processo de desenvolvimento.
Desafios e Objetivos
A SISC tem um balanço bastante positivo, mas com as metas de expansão determinadas pelos sócios começa a esbarrar em alguns obstáculos devido ao seu crescimento pouco planejado e estruturado. A diretoria da SISC definiu alguns objetivos para a otimização de processos a ser implantada:
1. Tornar possível o reuso de requisitos;
2. Melhorar a qualidade do produto;
3. Melhorar a produtividade da equipe;
4. Aumentar a capacitação técnica da equipe;
5. Melhorar a forma como são feitos os testes;
6. Entregar quatro atualizações do SISC Enterprise por ano, com melhorias significativas no produto, além das correções de bugs
A conclusão é que a SISC precisa de um processo de desenvolvimento de software bem estruturado que atenda as necessidades de crescimento da empresa e melhoria da qualidade e ritmo de desenvolvimento do produto a fim de suprir os desafios e atingir os objetivos propostos.
Implementação de um novo processo de desenvolvimento
O Rational Unified Process é um processo de engenharia de software. Ele oferece uma abordagem baseada em disciplinas, que nada mais é do que uma coleção de atividades relacionadas a uma área de interesse principal, 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ível.
As disciplinas abordadas pelo RUP são: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação, Gerência de Mudança, Gerenciamento de Projeto e Ambiente, onde cada uma delas tem objetivos bem definidos que serão executados por pessoas no projeto com papéis atribuídos e tendo como produto artefatos previamente estabelecidos.
A base do RUP é que ele é dividido nas fases de Iniciação, Elaboração, Construção e Transição ao longo do tempo do projeto onde as disciplinas são distribuídas e irão evoluindo utilizando o conceito de iteração.
Neste documento não entraremos nos detalhes das fases, disciplinas e artefatos, sendo proposto um workshop para isso.
Para que se possa ter uma visão mais clara da interação entra as fases e as disciplinas do RUP, apresentamos o gráfico abaixo:
Podemos resumir que RUP é baseado em um conjunto de princípios de desenvolvimento de software e melhores práticas como por exemplo:
1. Desenvolvimento de software iterativo
2. Gerenciamento de requisitos
3. Uso de arquitetura baseada em componente
4. Modelagem visual de software
5. Controle de alteração no software
Analisando o processo atual da SISC, visando uma melhoria nos processos e mais qualidade no desenvolvimento de software propomos uma customização do RUP adequando às necessidades da empresa.
As disciplinas do RUP nos permitirão atacar de uma maneira objetiva os problemas detectados no processo de desenvolvimento e principais reclamações de clientes.
Para implantação do RUP, propomos que algumas disciplinas tenham mais ênfase do que outras. A escolha dessas disciplinas se dará devido à prioridade das necessidades da SISC.
· Modelagem de negócios: entender os problemas atuais da SISC e identificar as possibilidades de melhoria
· Requisitos: padronizar e documentar o levantamento de requisitos que já é realizado hoje
· Análise e Design: no momento não é necessária implementação desta disciplina pois o software já está desenvolvido. Porém para inclusão de mais módulos ou novos projetos ela deverá ser implementada.
· Teste: padronizar e documentar os procedimentos de testes.
· Implantação: no momento essa disciplina não será implementada pois não foram identificados problemas na implantação do software nos clientes.
· Gerência de Mudança: um dos problemas detectados foi em relação as customizações do software nos clientes e a difícil manutenção disso. Com esta disciplina este problema será solucionado permitindo a satisfação dos clientes finais, maior organização da SISC, maior aproveitamento do tempo devido a não ter mais retrabalhos e atingir a meta de liberação de mais builds por ano.
· Gerenciamento de Projeto: enfatizar os aspectos de um processo de desenvolvimento iterativo como gerenciamento de risco, planejamento de um processo iterativo e monitoramento do mesmo.
· Ambiente: é nesta disciplina que faremos a customização do RUP para a SISC.
Estratégia de implementação
Alterar o processo de desenvolvimento em uma empresa é uma tarefa árdua e possui diversos fatores críticos de sucesso, sendo que o mais importante deles é o comprometimento das partes envolvidas. É necessário que a diretoria entenda perfeitamente a extensão das mudanças feitas e que esta permeia por todo o departamento de desenvolvimento, por isso é de extrema importância que a diretoria participe ativamente principalmente na parte inicial onde serão definidos e refinados quais objetivos deverão ser alcançados e as expectativas para cada objetivo.
Sabemos que a simples apresentação de um processo não será suficiente pois este somente mostra o que fazer mas não como. Por isso propomos em conjunto com um projeto piloto serem feitos treinamentos nas ferramentas que serão selecionadas posteriormente para auxilio da metodologia junto com a definição do projeto piloto, integrando assim os conhecimentos das ferramentas com a metodologia e processo.
Mediante análise da empresa SISC, é notado que devido a sua complexidade é impossível implementar o RUP em todos os projetos pilotos de uma única vez. Por isso é proposta uma abordagem de implementação em fases. Serão definidos cerca de 3 projetos a ser usado como piloto para a implementação e adequação do RUP, tendo também como fim envolver outras partes do departamento de desenvolvimento onde também será construída uma base de profissionais treinados na metodologia que servirão de mentores para a disseminação do processo para o restante dos projetos.
O projeto piloto em si deve ter algumas características chave:
· Riscos técnicos gerenciáveis, o projeto não pode ser de altíssimo risco tendo em vista não colocar muita pressão sobre o mesmo prejudicando o processo de aprendizagem
· Prioridade alta, porem o projeto não pode ser de pouca importância para que não seja deixado de lado por qualquer outra prioridade e também a fim de utilizar o processo a ser implementado em projetos que sejam mais comuns no departamento de desenvolvimento
· Equipe comprometida, este é um ponto chave de sucesso pois para que o novo processo seja facilmente implementado é necessário que a equipe tenha interesse em aprender e não seja resistente a mudanças
· Cronograma realista, a data de entrega não pode ser critica pois é esperado que os projetos pilotos tenham uma produtividade menor nas fases iniciais dos primeiros projetos pois é necessário o tempo para aprender. Nós estimamos que seja necessário aproximadamente 4 semanas extra para aprendizagem do novo processo, ferramentas e métodos.
É provado que a melhor forma de aprendizagem é a combinação de teoria e prática, por isso propomos que alem de ser fornecido material de suporte, antes do início do projeto todos os envolvidos deverão passar por um workshop “RUP na SISC” para entender o que será alterado e por quê. Após isso um treinamento de 2 dias com os fundamentos do RUP para que seja iniciado o projeto piloto, então serão feitos treinamentos de metodologias e ferramentas respectivas à fase que o projeto piloto se encontra. Além disso um especialista deverá cuidar da parte de mentoring a fim de sanar eventuais dúvidas teóricas durante o processo de desenvolvimento do projeto e acompanhar o desenvolvimento do uso do novo processo.
Durante o projeto piloto serão apresentados avaliações dos resultados obtidos mostrando os pontos de melhora da produtividade e qualidade do software, além dos objetivos aqui apresentados que já foram alcançados. Depois de estabelecido um senso comum sobre qual a customização do processo que melhor se aplica a SISC e deixado isto bem definido é feita uma preparação do ambiente para a utilização desse processo nos outros projetos novos. Nesta fase os participantes dos projetos pilotos serão de grande importância para serem mentores e auxiliar na utilização do processo durante os novos projetos.
Resultados Esperados
Em longo prazo os efeitos esperados pelo uso de um novo processo de desenvolvimento são:
Requisitos de negócio bem definidos como entrada do processo
Melhor adequação as reais necessidades do cliente na hora da entrega
Menor tempo de entrega para as versões
Mais projetos entregues dentro do prazo e orçamento
Redução dos custos de re-trabalho
Melhor manutenção do produto
Um processo de desenvolvimento de aplicações comum
Acreditamos que seja possível uma grande melhora significativa nos resultados da empresa e qualidade do produto em curto-médio prazo, sendo que no prazo de 2 a 3 anos todos os objetivos aqui apresentados estejam completamente alcançados e possibilitando um controle bem maior sobre as solicitações dos diversos clientes possibilitando assim uma grande melhoria na qualidade de atendimento dos chamados como também uma fácil reutilização das customizações já feitas.
Assinar:
Postagens (Atom)