IBM Brasil e parceiros lançam site e curso gratuito de inglês à distância

São Paulo - 02 Set 2010: O déficit de profissionais de tecnologia da informação (TI) no mercado brasileiro, atualmente estimado em mais de 70 mil pelo Observatório Softex (Unidade de Estudos e Pesquisas da Sociedade), fez com que a IBM Brasil desse mais um passo no sentido de contribuir para a formação de mão-de-obra. A empresa, bem como o mercado brasileiro, enfrentam não só a falta de profissionais especializados, mas também um outro problema: a carência de profissionais que falam inglês. Diante deste cenário, a IBM decidiu investir na criação de um curso de inglês à distância. Chamado de ‘English4Smart’, é totalmente gratuito e feito especificamente para estudantes de TI. O curso, assim como temas ligados à área, ficarão hospedados no portal ‘TI Smart’ (www.ti-smart.com.br), lançado pela companhia com apoio de parceiros.

O ‘English4Smart’ é voltado ao inglês utilizado no mundo dos negócios e seu conteúdo foi desenvolvido pelo instituto de idiomas União Cultural Brasil Estados Unidos, que também irá disponibilizar certificados digitais aos participantes. “Para ingressar em uma empresa globalmente integrada como a IBM não basta que o candidato conheça tecnologia, é necessário estar ao menos no nível intermediário de inglês. Uma das áreas que mais geram oportunidades de emprego na IBM é a de exportação de serviços. Por isso, o conhecimento do inglês é fundamental. É importante acelerar a formação dos profissionais para acompanhar o crescimento do mercado”, afirma Edson Luiz Pereira, gerente de parcerias educacionais da IBM Brasil.

Maiores informacoes:

http://www-03.ibm.com/press/br/pt/pressrelease/32424.wss

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com

Novo Blog: Desenvolvimento de Sistemas com C# e Visual Studio

Olá, pessoal.

Gostaria de lhes recomendar o blog de um amigo meu, sobre desenvolvimento de sistemas usando C# com Visual Studio: http://csharptoolbox.blogspot.com/

Bons estudos!

Abraço,

Marcelo Schumacher
marcelo.schumacher@gmail.com
http://isosoftware.blogspot.com/

Oportunidade de Trabalho

Oportunidade de Trabalho na CWI

Desenvolvedor .NET

Requisitos:

- Perfil Pleno.

- Conhecimentos em ASP.NET 2.0, C, Microsoft SQL Server 2005, WebServices, Windows Form e Crystal Reports.

Local de Trabalho: Porto Alegre.

Número de Vagas: 01.

Desenvolvedor .NET

Requisitos:

- Perfil Pleno.

- Experiência em desenvolvimento de sistemas em C Sharp e ASP.NET, SOA e desenvolvimento de componentes.

- Experiência mínima de 3 anos na função.

Local de Trabalho: Porto Alegre.

Número de Vagas: 04.

Desenvolvedor .NET

Requisitos:

- Perfil Sênior.

- Experiência em desenvolvimento de sistemas em C Sharp e ASP.NET, SOA e envolvimento de componentes.

- Experiência mínima de 4 anos na função.

Local de Trabalho: Porto Alegre.

Número de Vagas: 04.

Desenvolvedor Java Pleno

Requisitos:

- Experiência de dois anos ou mais em projetos de desenvolvimento de sistemas

- Conhecimentos em: Struts, Hibernate e SQL (preferencialmente em Oracle e PostgreSQL)

Local de Trabalho: Farroupilha – RS.

Número de Vagas: 01.

Estagiário Java

Requisitos:

- Possuir bons conhecimentos no desenvolvimento em Java/JSP.

- Necessário estar cursando faculdade na área de TI.

Local de Trabalho: São Leopoldo.

Número de Vagas: 01.

Analista Projetista

Requisitos:

- Perfil Sênior.

- Experiência em C Sharp e ASP.NET, SOA, desenvolvimento de componentes, WCF (Windows comunication foundation), WebServices, WindowsServices e XML.

- Experiência mínima de 4 anos.

Local de Trabalho: Porto Alegre.

Número de Vagas: 02.

Analista de Qualidade Sênior

Requisitos:

- Experiência em planejamento e execução de testes de sistemas,

- Vivência em projetos de desenvolvimento de software,

- Superior completo na área de TI.

- Experiência de no mínimo 5 anos na área de qualidade.

Local de trabalho: Porto Alegre.

Número de Vagas: 01.

Desenvolvedor C

Principais atividades:

- Desenvolvimento e manutenção de sistemas de alto desempenho em ambiente multithread distribuído (cliente multinacional).

Requisitos:

- Fundamental conhecimento em C/ANSI,

- Domínio de Linux e conhecimentos de scripts Shell, CVS, Makefiles e pacotes RPM,

- Bons conhecimentos de SQL, HTML e javascript.

Local de Trabalho: Porto Alegre.

Número de Vagas: 01.

Desenvolvedor Java Peno

Requisitos:

- Conhecimento de JAVA, importante conhecer e ter experiência em JAVA Swing.

- Desejável: experiência em Oracle e PL/SQL. Ter conhecimento em Linux e em Sistemas de Vendas (PDV, emissão de cupom fiscal).

Local de Trabalho: São Leopoldo.

Número de Vagas: 01.

Desenvolvedor JAVA

Requisitos:


- Perfil Sênior,

- Dominio de java e frameworks de mercado (swt/swing, hibernate, struts, commons, spring, ireport),

- Bons conhecimentos de ferramentas de gerencia de configuração (svn, maven).

Local de Trabalho: Porto Alegre.

Número de Vagas: 01.

Desenvolvedor JAVA

Principal Atividade:

- Implementar as especificações técnicas definidas para o sistema.

Requisitos:

- Experiência de três anos ou mais em projetos de desenvolvimento de sistemas,

- Conhecimentos em: Struts, Hibernate, Spring, Java Web.

Local de Trabalho: Porto Alegre.

Número de Vagas: 03.

Desenvolvedor PL/SQL

Requisitos:

- Experiência em PL/SQL,

- Domínio de HTML.

Local de Trabalho: São Leopoldo.

Número de Vagas: 02.

Desenvolvedor VB.NET

Requisitos:

- Experiência em VB.NET, ADO.NET, Microsoft SQLServer 2005, elaboração de Stored Procedures, desenvolvimento em camadas.

- Desejável conhecimentos em Windows Service, SSIS e Reporting Services.

- Mínimo 2 anos de experiência.

Local de Trabalho: São Leopoldo.

Número de Vagas: 01.

Currículos podem ser encaminhados para rh@cwi.com.br

Evento: Dia Q debate Gerência da Configuração em Abril

Evento: Dia Q – Qualidade de Software em Debate

Tema: Qualidade na integridade de dados e ativos através da Gerência de Configuração

Data: 07/04/2010 quarta-feira

Horário: 18h20 as 19h20

Local: Auditório do bloco O, centro 6 da Unisinos

Evento gratuíto e sem necessidade de inscrições prévias.

Debatedores:

Nilseu Padilha da Ilegra

Nilseu Padilha é arquiteto de software da ilegra. Tem mais de 12 anos de atuação em Tecnologia da Informação. É bacharel em Ciência da Computação pela ULBRA e mestre em Ciência da Computação, ênfase em Engenharia de Requisitos, pela PUCRS. Leciona Estruturas de Dados, Java e Banco de Dados na FAQI. Tem experiência em tecnologias Java, Oracle, Open Source e em métodos de Gerência de Configuração, Engenharia de Requisitos e Gerência de Projetos.

Josiane Brietzke Porto da Qualità

Pós-graduada em Melhoria de Processos de Software pela UFLA em 2008. Bacharel em Ciência da Computação pelo UNILASALLE em 2005. Autora de diversos artigos nacionais e internacionais na área de qualidade de software (ASSE 2005, WIS 2005, CLEI Eletronic Journal, W2–MPSBR, SBQS 2007, W6-MPS.BR e Engenharia de Software Magazine). Experiência de mais de 5 anos na área de TI, atuando em desenvolvimento de software e de mais de 4 anos na área de qualidade e melhoria de processos utilizando como referência SW-CMM, CMMI, MR-MPS, PMBOK, RUP, ISO/IEC 12207 e 15504 e ISO 9001:2000. Implementadora MR-MPS desde 2004, Certified Quality Improvement Associate (CQIA) de 2006 a 2009. Atua desde 2005 na Qualità Informática em projetos de melhoria de processos baseados em MPS.BR e PGQP e de desenvolvimento de aplicações WEB.

Estimando o Esforço para o Desenvolvimento de Software

Nos últimos meses tenho enfrentando grandes dificuldades para conseguir estimar tempos necessários de desenvolvimento nos projetos em que participo.

Eu tenho convicção de que as melhores práticas de se calcular estimativas necessitam de um mapeamento coerente dos requisitos de software. Mas, nas maioria empresas de desenvolvimento de software, a aplicação de métodos de gerenciamento de requisitos ainda  precisa ser amadurecido. Ou seja, não são aplicados. Em razão disso, é preciso adaptar-se à realidade e tentar soluções alternativas.

Trantando-se de tentar entender o tempo e os custos para se determinar uma estimativa de desenvolvimento, em geral, pode variar conforme a fase do processo de desenvolvimento. Nas fases iniciais a estimativa tende a ser pouco precisa. Normalmente o nível de estimativa dividi-se da seguinte forma:

Planejamento: Fase inicial. Contempla entradas grosseiras, estimativas pouco fiéis, requisitos em altíssimo nível, arquitetura conceituall;

Especificação: Pode ser compreendida como a fase inicial do projeto. O projeto já é melhor entendido, as estimativas são mais fiéis, os requisitos também são melhor entendidos e a arquitetura começa a ser compreendida;

Construção: Aborda a fase de conecpção do software de acordo com o que foi especificado. Já contempla um projeto bem caracterizado, estimativas com alta precisão, requisitos e arquitetura mais estáveis;

Uma das téncicas existentes para estimarmos o tempo de desenvolvimento, visando também compreender os custos associados, é o COCOMO de forma básica.

No modelo COCOMO, o esforço das fases iniciais é calculado considerando as equações abaixo:

Esforço = Ab * (Tamanho) * exp(Bb),

Tempo_Desenvolvimento = Cb * (Esforço * exp(Dd)) onde;

Esforço = número de homens/hora ou homens/hora;

Tempo_Desenvolvimento = tempo em meses cronológicos;

Tamanho = número de pontos de função;

Aa e Bb são coeficientes, Cb e Db são exponeciais de ajustes fornecidos pela seguinte tabela:

 TABELA 1 - Coeficientes do Método COCOMO

Neste modelo básico do COCOMO, o esforço e o custo do projeto é estimado em função do tamanho do código estimado, considerando um modelo estático. Outras formas de aplicação do COCOMO consideram avaliações subjetivas do produto, do hardware, do pessoal e dos atributos do projeto, além do impacto nas fases que direcionam os custos (análise, por exemplo).

Algumas das ferramentas existentes que permitem calcular as estimativas usando o COCOMO são:

• BYL, Gordon Group;
• WICOMO, Wang Intitute;
• DECPlan, Digital Corporation;

Tendo estimado o esforço do projeto, aplicando o COCOMO, por exemplo, podendo ser melhorado e refinado a cada iteração, teremos condições de fazer uma estimativa de custo para o projeto, onde os componente abaixo são fundamentais:

• Esforço em homens/hora * Custo(incluindo impostos);
• Infra-estrutura (hardware, software e ambiente);
• Overhead administrativo: corresponde numa variação de 20 a 30% do valor total estimado.

Os pontos assinalados acima servem apenas para complementar a definição de uma estimativa de desenvolvimento, não fazendo parte do método COCOMO.

Apesar de eu ter lhes apresentado esta alternativa de cálculo de estimativas, eu não venho aplicando-a no meu dia-a-dia. No momento, utilizo uma outra técnica chamada DELPHI (Se pronuncia Délfi). Assim que tiver oportunidade, postarei um tópico esclarecendo este segundo método.

Oportunidade de Trabalho

Divulgando a pedidos:

Prezados,

Estamos entrando em contato para divulgar uma de nossas oportunidade visando atender um de nossos clientes.

Contamos com seu apoio para divulgar para possíveis interessados.

ANALISTA PROGRAMADOR
Para indústria eletrônica situada em Porto Alegre

Requisitos:
- Ensino superior completo ou cursando em áreas afins
- Experiência anterior em desenvolvimento de programas
- Conhecimento avançado em: ASP, VB.Net, Mysql e Microsoft Access

Interessados enviar currículo para thais@apassessoria.com.br

Indicações serão bem vindas!

Muito obrigada!

Att
Thais Galvani
AP Assessoria em RH
Av. Carlos Gomes, 141/1202
Bairro Auxiliadora - CEP: 90480.003
Porto Alegre - RS
Tel.: 51 2102.0307 / Fax: 51 2102.0303
E-mail: thais@apassessoria.com.br
www.apassessoria.com.br

Como iniciar o Processo Unificado (PU)

Em posts anteriores lhes apresentei uma abrangência conceitual sobre o Processo Unificado (PU). Hoje, pretendo lhes mostrar um pouco sobre como executar na prática o uso do PU.

O PU é dividido em disciplinas distribuídas em 4 fases, conforme apresentado na FIGURA 1. Cada fase contém um conjunto de iterações cuja periodicidade de cada iteração é definida de acordo com o planejamento de um projeto.

FIGURA 1 - Disciplinas, Fases e Itrações do PU

Os resultados das aplicações dos trabalhos seguindo o PU geram artefatos, ou seja, documentos, diagramas, modelos, protótipos, etc. Entretanto, praticamente todos são opcionais. Logo, quando planejar o projeto é preciso definir quais os artefatos serão indispensáveis para atender os problemas e necessidades do determinado projeto.

O resultado da definição de quais artefatos serão utilizados podem ser descritos num documento sucinto que dentro do PU é denominado “Pasta de Desenvolvimento”. Basicamente, é um documento que abrange uma listagem dos artefatos que serão usados em cada disciplina, fase e iteração do projeto. Na FIGURA 2 é possível observar um exemplo deste documento.

FIGURA 2 - Amostra de Artefatos Definidos para o Projeto

Na FIGURA 2 o “i” representa “iniciar” e o “r” representa “revisão”. Esta figura representa um modelo, isto é, outros artefatos poderiam ter sido listados. Isto realmente depende do projeto.

Espero ter conseguido lhes explanar como dar o “start” no uso do PU. A partir de agora começaremos a dar uma abordagem sobre os artefatos que são gerados dentro do PU.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com/

Bibliografia:

LARMAN, Craig. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. Tradução Rosana Vaccare Braga. 3ª edição. Porto Alegre: Bookman, 2007;

Oportunidade de Trabalho

Programador de BI

Objetivo: atuar como programador de sistemas de Business Intelligence utilizando a plataforma Microsoft SQL Server.

Conhecimentos:

- Programação e análise de sistemas;

- Modelagem de BD;

- Transaction SQL;

- SQL Server 2000, 2005 ou 2008.

- Curso superior em andamento ou completo na área de informática ou qualquer curso superior com especialização na área de informática; e,

- Certificação MCPD (Microsoft Certified Professional Developer) ou MCAD .NET (Microsoft Certified Application Developer for Microsoft .NET).

- Desejável conhecimento em Business Intelligence e Reporting Services utilizando a plataforma Microsoft SQL Server.

Enviar CV para: rh@pandorga.com.br

Pandorga Tecnologia

www.pandorga.com.br

Abrangência sobre as Disciplinas do Processo Unificado (PU)

Conforme vimos, o Processo Unificado (PU) trata de um framework que orienta um processo de desenvolvimento. Ele abrange várias disciplinas onde o exercício de cada disciplina possui etapas e o resultado da execução destas etapas em cada disciplina é o produto de software concebido com qualidade.

Cada etapa possui “n” fases, ou iterações, que correspondem ao andamento do trabalho de desenvolvimento. A iteração é um período de tempo, definido no início do projeto. Por exemplo, cada iteração pode durar 5 dias e haverá 3 iterações por etapa. A idéia é que no final das iterações o projeto esteja concluído.

FIGURA 1 – Disciplinas, Fases e Iterações do PU

Na FIGURA 1 é possível observar a relação existente entre as fases em cada disciplina do PU. Durante cada iteração o processo segue na maioria das disciplinas até que o trabalho esteja concluído. Todavia, o esforço aplicado em cada disciplina aumenta ou diminui conforme o andamento das fases do projeto. Por exemplo, conforme observamos na figura, a disciplina de “Modelagem de Negócios”, na fase de “Iniciação” possuí um grande esforço e conforme as demais fases (Elaboração, Construção e Transição) vão ocorrendo reduz o esforço, chegando a fase de “Transição” praticamente sem haver ainda esforços nesta disciplina.

Ou seja, as iterações iniciais tendem a ter uma ênfase maior no levantamento de requisitos, no projeto e na determinação do trabalho a ser desenvolvimento. Por sua vez, as últimas disciplinas dão uma ênfase menor a menor na fase inicial do projeto.

Agora, conforme o projeto tem seu andamento realizado, aumentam os esforços nas disciplina de implementação, testes e demais disciplinas que tangem a construção e a finalização do trabalho, reduzindo o esforço das etapas de levantamento de requisitos.

Este parece ser um processo aparentemente natural do ponto-de-vista conceitual. Isto é, a maioria acredita que é desta forma que um processo de desenvolvimento de software ocorre no seu ambiente de trabalho, mas, estão enganados. Aplicar um processo destes exige comprometimento e disciplina por parte dos executores, além do apoio da gestão. Cada disciplina citada gera determinados artefatos (documentos, imagens, diagramas, etc.) que determinada fase foi atendida e determinada iteração da fase foi cumprida com sucesso, atendendo às restrições definidas no início do planejamento do projeto.

Espero ter ajudado a elicitar um pouco mais sobre como formalizar e organizar um processo de desenvolvimento de tal forma que ele tenha com clareza um início, um meio e um fim. Em breve pretendo abordar ainda mais este assunto, pois ele é fundamental para se atingir a Qualidade no processo de desenvolvimento de software.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com

Bibliografia:

LARMAN, Craig. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. Tradução Rosana Vaccare Braga. 3ª edição. Porto Alegre: Bookman, 2007;

Oportunidade de Trabalho

Audax Dreams, empresa com sede na incubadora da Unisinos (UNITEC), oferece estágio para a seguinte vaga:

Programador Web

Como principais atividades estarão a manutenção e criação de sistemas web internos, de apoio a operação da Audax Dreams, e externos, de clientes dos nossos serviços de desenvolvimento web.

Requisitos:

• Graduação em andamento ou concluída em Ciência da Computação, Sistemas de Informação, Desenvolvimento de Sistemas, Jogos Digitais ou cursos técnicos relacionados a desenvolvimento de sistemas;

• Experiência profissional ou acadêmica em programação web "server side" com ASP Clássico, ASP .Net, PHP, JSP ou similares;

• Experiência profissional ou acadêmica em SQL (ANSI): entendimento e const rução de queries de seleção, inclusão e remoção de registros em SGBD SQL SERVER, ORACLE,

MySQL, FIREBIRD ou similares;

• Experiência profissional ou acadêmica em programação web "client side" com Javascript;

• Experiência profissional ou acadêmica em manipulação de interfaces web (HTML e CSS);

Diferencial:

• Experiência profissional ou acadêmica em programação web "server side" com ASP Clássico e/ou ASP .Net;

• Experiência profissional ou acadêmica em VBScript (scripts shell e web "client side") ou VBA;

• Experiência profissional ou acadêmica em SQL proprietário ORACLE (PL/SQL) e SQL

SERVER (T-SQL);

• Noções de ActionScript, AJAX, WEBSERVICES e paradigma SOA;

• Conhecimento sólido do paradigma de programação web;

Oferecemos bolsa-auxílio compatível com o mercado, transporte, alimentação e possibilidade de efetivação.

Enviar Curriculum Vitae para rh@audaxdreams.com com o texto “[WEBDEV-201002]“ no assunto do e-mail.

Processo Unificado - PU (Unified Process)

Seguindo na linha de abordagens de conceitos importantes para a busca da Qualidade no processo de desenvolvimento de software, gostaria de lhes apresentar um padrão de processo de desenvolvimento amplamente aplicado chamado Processo Unificado (PU), em inglês Unified Process.

O PU surgiu como um processo iterativo/evolutivo popular para o desenvolvimento de software, visando a construção de sistemas orientado a objetos. (LARMAN, 2007).

O PU é um framework customizável e passível de adaptações. Inclusive, outros padrões comercias existentes usam como base o PU, contemplando apenas alguns refinamentos, dentre eles: Rational Unified Process (RUP da IBM), Agile Unified Process (AUP) e o Enterprise Unified Processo (EUP).

Conforme mencionado, o PU é um processo iterativo/incremental. Processos com estas características consistem em realizar o desenvolvimento organizado em uma série de miniprojetos curtos, de duração fixa (por exemplo, 4 semanas) chamados de iterações. O produto resultante de cada iteração é um sistema parcial, executável, testável e funcional. Cada iteração inclui suas próprias atividades de análise de requisitos, projetos, implementação e testes. Assim, o sistema vai sendo complementado a cada iteração e cresce incrementalmente, de forma evolutiva (LARMAN, 2007).

Um projeto PU organiza o trabalho e as iterações em quatro fases principais:

- Iniciação: visão aproximada, casos de negócio, escopo e estimativas vagas;

- Elaboração: visão refinada, implementação iterativa da arquitetura central, resolução dos riscos elevados, identificação da maioria dos requisitos e do escopo e estimativas mais realistas;

- Construção: implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação;

Na FIGURA 1 é possível verificar este ciclo de desenvolvimento de forma gráfica.

FIGURA 1 – Ciclo de Desenvolvimento do PU

O PU também é dividido em disciplinas que consistem nas atividades a serem executados em cada fase do processo de desenvolvimento. Em cada disciplina são elaborados artefatos cuja concepção garante o devido andamento do processo de desenvolvimento. A seguir são apresentadas as disciplinas do PU:

- Modelagem de Negócio: desenvolve-se o Modelo de Domínio, para visualizar conceitos importantes no domínio da aplicação;

- Requisitos: são criados os modelos de Caso de Uso (UC) e Especificação Suplementar (SER) para captar requisitos funcionais e não funcionais;

- Projeto: é criado o Modelo de Projeto para vislumbrar os objetivos do software;

- Implementação: codificação, construção do sistema;

- Testes: consiste em realizar a verificação do funcionamento da implementação realizada, de acordo com o modelo de UC elaborado;

- Desdobramentos: implantação do sistema;

- Gestão de Configuração e Mudança: aplicação de padrões de código-fonte, preparação de scripts de mudanças em base de dados;

- Gestão de Projetos: atualização dos checkpoints, dos cronogramas, da comunicação aos stakeholders;

- Ambiente: estabelecimento do instrumental e a personalização do processo para um projeto, ou seja, a preparação do ambiente do processo e das ferramentas necessárias.

FIGURA 2 – Disciplinas do PU

Em próximas postagens pretendo abordar mais informações referentes ao uso de processos de software, principalmente o que tange o Agile Unified Process (AUP) que está tornando-se cada vez mais necessária num ambiente de fábrica de software.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com

Bibliografia:

LARMAN, Craig. Utilizando UMLe Padrões: Uma introdução à análise e ao projeto orientados 

a objetos e ao desenvolvimento iterativo. Porto Alegre: Bookman, 2007;

Oportunidade de Trabalho

TOTVS SAÚDE

Unidade localizada em Porto Alegre - RS

ANALISTA DE TESTES

Exigências: Profissional com experiência na execução e na construção de análises de testes, bom relacionamento interpessoal, conhecimento em banco de dados Oracle.

Desejável: Conhecimento sobre a área da saúde (suplementar e/ou pública) e automação de testes.

Atividades: Construir análises de teste baseada em documentação de negócio e de sistema. Controlar prazo e execução de cronograma.

Benefícios: Auxílio Transporte + Vale Refeição + Plano de Saúde

Contratação: Cooperativa ou PJ

Observações: Interessados enviar currículo para arthur.heineck@totvs.com.br com pretensão salarial indicando no assunto o cargo.

TESTADOR DE SOFTWARE (JÚNIOR E PLENO)

Exigências: Profissional crítico, detalhista, com capacidade/facilidade de identificação de falhas e documentação.

Desejável: Experiência na execução de teste de software. Conhecimento em programação e banco de dados.

Benefícios: Auxílio Transporte + Vale Refeição + Plano de Saúde

Contratação: Cooperativa

Observações: Interessados enviar currículo para arthur.heineck@totvs.com.br com pretensão salarial indicando no assunto o cargo.

DESENVOLVEDOR .NET

Exigências: Conhecimentos em ASP.NET, C#, Java script , XML, HTML, DHTML, CSS, AJAX, banco de dados Oracle e SQL Server. Conhecimentos em Orientação a Objetos e UML.

Desejável: Certificação MCAD para Microsoft .NET.

Benefícios: Auxílio Transporte + Vale Refeição + Plano de Saúde

Contratação: Cooperativa

Observações: Interessados enviar currículo para luciano.deoliveira@totvs.com.br com pretensão salarial indicando no assunto o cargo.

Uso de Padrões para Melhorar a Qualidade

Hoje, gostaria de lhes descrever sobre a existência e a importância do uso de padrões que auxiliam na melhoria da Qualidade sobre produtos de Software.

Dentro de um contexto onde há um processo de desenvolvimento de software é possível aplicar padrões variados para codificação, versionamento, análise, modelagem, interfaces, documentações, em suma, uma série de áreas onde seria possível determinar padrões que visam melhorar o processo de desenvolvimento do software. 

O desenvolvimento de software tem se tornado mais complexo ao longo dos anos. As exigências por parte dos clientes são cada vez maiores, em termos de produtividade, qualidade de software e prazos cada vez menores (MASSONI, 2003). O surgimento de novas tecnologias e a necessidade de realização de mudanças nos softwares desenvolvidos para atender às exigências dos clientes também dificulta a tarefa de desenvolver software com qualidade. Acompanhar as mudanças tecnológicas e atender às necessidades de mudança pode ser uma tarefa bastante complicada se o software não estiver preparado para suportar essas mudanças.

Alguns estudos sugerem que pouco mais da metade do esforço utilizado para o desenvolvimento de software esteja voltado para atividades que assegurem a qualidade de software. Dois recursos utilizados como forma de buscar o desenvolvimento de software com qualidade são a utilização de processos de desenvolvimento de software e a utilização de padrões (OSTERWEIL, 1996). 

No processo de desenvolvimento de software, duas questões essenciais devem ser consideradas para assegurar a qualidade: o fornecimento de técnicas que auxiliem no desenvolvimento de software de qualidade e técnicas que assegurem os atributos de qualidade exigidos nos artefatos existentes (ZUZER, 2005). Em razão disso, a utilização de padrões durante o processo de desenvolvimento pode ser uma das técnicas utilizadas para assegurar a qualidade dos artefatos gerados.

Muitos dos artefatos criados durante um processo de desenvolvimento de software são comuns a vários sistemas. Muitas vezes as mesmas técnicas são utilizadas para a criação desses documentos e, consequentemente, os mesmos problemas são encontrados. Os padrões apresentam uma forma de descrever soluções para estes problemas comuns, baseando-se na experiência de outras pessoas. Existem diversos tipos de padrões que podem ser utilizados para auxiliar na criação dos artefatos gerados em um processo de desenvolvimento de software. Padrões de projeto (GAMMA, 2000) e padrões de análise (FOWLER, 1997) são apenas alguns dos diversos tipos de padrões disponíveis e que poderiam ser utilizados juntamente com o processo de desenvolvimento para buscar o desenvolvimento de software com qualidade.

Neste post a idéia era destacar a existência de padrões e porque eles existem. Em breve, pretendo descreve mais detalhadamente alguns padrões de Análise e Desenvolvimento de software. 

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com 

Bibliografia:

FOWLER, Martin. Analysis Patterns: Reusable Object Models. Indianapolis: Addison-Wesley, 1997;

GAMMA, Erich; et al. Elements of Reusable Object-Oriented Software. Tradução de Luiz A.Meirelles Salgado. Porto Alegre: Bookman,2000;

MASSONI, Tiago; SAMPAIO, Augusto; BORBA, Paulo. A RUP-Based Software Process Supporting Progressive Implementation. Recife: Universidade Federal de Pernambuco, 2003. Disponível em: . Acesso em 23/10/2008;

OSTERWEIL, Leon, et. al. Strategic Direction in Software Quality. Amherst: University of Massachusetts, 1996. Disponível em: . Acesso em 23/10/2008;

ZUZER, Wolfgang; HEIL, Stefan; GRECHENIG, Thomas. Software Quality Development and Assurance in RUP, MSF and XP – A Comparative Study. New York: ACM Press, 2005. Disponível em: >. Acesso em 23/10/2008.

Minimizando Problemas com Requisitos – Parte 4 (Última)

Nos posts anteriores discutimos a respeito dos problemas comuns existentes com os requisitos de software, do conceito de gerenciamento de requisitos, fundamental para se aplicar as técnicas e de suas técnicas de gerenciamento aplicadas.

Hoje, pretendo lhes apresentar algumas ferramentas de mercado usadas para realizar o rastreamento de requisitos de software, uma das técnicas de gerenciamento de requisitos que lhes apresentei.

É fundamental a compreensão dos conceitos de requisitos e de gerenciamento de requisitos para conseguir interpretar as técnicas que serão descritas abaixo. 

IBM® Rational® RequisitePro® 7.1

O IBM Rational RequisitePro mantém equipes de projeto dentro da programação, permitindo a criação, análise e gerenciamento dos requisitos de aplicativo e casos de utilização. Além disso, é um poderoso aplicativo de fácil utilização para gerenciamento de requisitos e casos de utilização que promove melhor comunicação, aprimora o trabalho em equipe e reduz o risco de projeto. Assim, visa fornecer às equipes a capacidade de entender o impacto da alteração, assegurando que todos permaneçam informados sobre as informações de requisitos mais atuais para assegurar consistência (IBM, 2009).

FIGURA 1 - IBM® Rational® RequisitePro® 7.1

Borland® CaliberRM™

Ferramenta de software corporativa para o gerenciamento de requisitos que facilita a colaboração, a análise de impacto e a comunicação, permitindo que as equipes de software avancem o projeto com maior precisão e previsibilidade. Possui um repositório centralizado e adapta-se aos seus processos. Além disso, permite realizar a rastreabilidade completa dos requisitos de software, permitindo inclusive conectá-los a uma variedade de artefatos utilizados no ciclo de vida (BORLAND, 2009).

FIGURA 2 - Borland® CaliberRM™

DOORS®

Trata-se de um aplicativo de gerenciamento de requisitos que pode ajudar a reduzir custos, aumentar a eficiência e melhorar a qualidade, permitindo otimizar os requisitos de comunicação, colaboração e verificação, em toda a organização. Possuí módulo de acesso Web, minimizando a necessidade de impressão de documentos sobre o andamento do projeto. Permite ter a captura dos requisitos de negócios validando o entendimento dos requisitos, podendo acompanhar durante o projeto, permitindo a avaliação da gerencia de mudanças com os envolvidos no projeto (BSA, 2009).

FIGURA 3 - DOORS®

Estas são algumas das ferramentas informatizadas que permitem realizar o gerenciamento de requisitos de software, apontando suas dependências e a rastreabilidade existente. Lembrem-se de que o conceito de gerenciamento de requisitos visa minimizar drasticamente problemas do processo de manutenção de software.

Eu tive a oportunidade de trabalhar com a ferramenta IBM® Rational® RequisitePro® 7.1.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com/ 

Bibliografia:

BSA, Brasil. DOORS. 2009. Disponível em: >. Acesso em: 10 nov. 2009. 

BOLRAND. Gerenciamento de Requisitos de Software – da Borland. 2009. Disponível em: . Acesso em: 10 nov. 2009. 

IBM. IBM Rational Requisito Pro – Brasil - Português. 2009. Disponível em: . Acesso em: 10 nov. 2009.

Minimizando Problemas com Requisitos – Parte 3

Nos posts anterior discutimos a respeito dos problemas comuns existentes com os requisitos de software e do conceito de gerenciamento de requisitos, fundamental para se aplicar as técnicas.

Hoje, gostaria de lhes apresentarei o seguimento dos conceitos de gerenciamento de requisitos, desta vez abordando especificamente as técnicas de gerenciamento mais usadas.

É fundamental a compreensão sobre o conceito de requisitos e de gerenciamento de requisitos para conseguir interpretar as técnicas que serão descritas abaixo.

Técnicas para Gerenciamento de Requisitos:

A rastreabilidade de requisitos trata-se de uma atividade manual e constantemente obrigatória para que se consiga garantir a organização dos requisitos.  Desta forma, é possível controlar as atividades de desenvolvimento e manutenção do software mantendo sempre a relação mais atual entre os requisitos. Se a rastreabilidade não for aplicada constantemente, a relação entre os requisitos torna-se obsoleta e inútil e dificilmente se conseguirá reconstruir ou atualizar estas relações. Em razão disso, é preciso adotar e aplicar uma técnica que permita realizar esta organização de requisitos. A seguir serão apresentadas algumas técnicas comuns de rastrabilidade de requisitos (WIEGERS, 2003). 

Matriz de Rastreabilidade de Requisitos e Elementos do Sistema:

Um dos métodos mais comuns de representação da relação entre os requisitos e os demais elementos do sistema de software é a matriz de rastreabilidade.

A FIGURA 1 ilustra uma modelo de matriz de rastreabilidade, contendo um exemplo de requisitos funcionais aprovados. A tabela apresenta a relação dos requisitos funcionais com seus respectivos Casos de Uso, referências de desenvolvimento, módulos que contemplam sua codificação e os respectivos elementos de testes. As referências de desenvolvimento podem incluir diagramas, modelagens, classes de negócio, dentre outros objetos ou artefatos pertinentes e relacionados ao determinado requisito funcional (WIEGERS, 2003).

FIGURA 1 – Matriz de Rastreabilidade de Requisitos (WIEGERS, 2003)

A rastreabilidade define relações um-para-um, um-para-muitos ou muitos-para-muitos entre os requisitos e seus elementos de software. O formato apresentado na TABELA 2.1 comporta esta relação, pois é possível definir uma lista de itens para cada célula. Considerando os atributos preenchidos na FIGURA 1 temos as relações (WIEGERS, 2003):  

-Um-para-um: uma referência de desenvolvimento é implementada em um módulo codificado;

-Um-para-muitos: um requisito funcional está relacionado a múltiplos casos de teste;

-Muitos-para-muitos: um caso de uso pode possuir diversos requisitos funcionais e um requisito funcional pode estar relacionado a diversos casos de uso. Da mesma forma, as referências de desenvolvimento podem estar relacionados a requisitos distintos e cada requisito pode contemplar diversas referências.

Outra maneira de representar a rastreabilidade das informações é através de um conjunto de matrizes que definem as ligações em pares entre os elementos do sistema, conforme FIGURA 2. É possível usar matrizes para representar diversas relações possíveis entre pares de requisitos, tais como “especificado / é especificado pelo”, “depende”, “é origem de” e “limitações / são limitadas por” (WIEGERS, 2003).

FIGURA 2 – Rastreabilidade entre Casos de Uso e Requisitos

A FIGURA 2 ilustra esta rastreabilidade bidirecional. A maioria das células desta matriz ficam em branco. Na intersecção entre as células de dois componentes está indicada se é uma relação do tipo “relacionado a”, “relacionado do” ou qualquer outro tipo de relação. Além disso, são utilizadas setas que indicam que determinado requisito funcional á relacionado a partir de um caso de uso. Este tipo de representação é mais propícia no uso de ferramentas automatizadas (WIEGERS, 2003). Na quarta e última parte, pretendo lhes apresentar ferramentas de mercado que auxiliam na realização dos trabalhos de gerenciamento de requisitos. 

Cordialmente, 

Marcelo Schumacher 
http://isosoftware.blogspot.com/  

Bibliografia:

WIEGERS, Karl E. Software Requirements. 2nd ed. Redmond: Microsoft Press, 2003.