isoSoftware / Qualidade de Software

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

2010-09-12T20:14:00.000-07:00

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

2010-07-29T09:42:00.000-07:00

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

2010-04-16T14:55:00.000-07:00

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

2010-04-06T17:46:00.000-07:00

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

2010-04-04T07:27:00.000-07:00

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

2010-03-17T17:30:00.001-07:00

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)

2010-03-13T08:10:00.000-08:00

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

2010-03-09T15:03:00.001-08:00

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)

2010-02-25T13:35:00.000-08:00

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:

Oportunidade de Trabalho

2010-02-23T13:36:00.000-08:00

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)

2010-02-02T05:12:00.000-08:00

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

2010-01-31T17:16:00.000-08:00

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

2010-01-17T08:01:00.000-08:00

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)

2009-12-16T16:17:00.000-08:00

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

2009-12-06T08:44:00.000-08:00

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.

Comunicado: Pausa para o TCC

2009-12-02T16:14:00.000-08:00

Pessoal.

Desculpem-me não ter postado nada na última semana. Mas, estou na reta final de apresentação do meu TCC na faculdade. Neste momento, estou preparando uma pré-apresentação para apresentar ao meu orientador e poder definir finalmente se está tudo de acordo para eu realizar a apresentação à banca.

Provavelmente, até o dia 09/12/2009 eu não consiga postar mais nada, porque realmente preciso me dedicar muito à apresentação do TCC.

Conto com a compreensão de todos os acompanhantes do blog e lhes prometo que quando terminar a apresentação voltarei a lhes apresentar conteúdo interessantes.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com

Minimizando Problemas com Requisitos – Parte 2

2009-11-21T07:03:00.000-08:00

No post anterior iniciamos a discussão sobre como conseguir minimizar os problemas enfrentados com os requisitos de software.

A solução mais aplicada é o Gerenciamento dos Requisitos e anteriormente vimos como que deve ser identificado um requisito de software para conseguir realizar o devido gerenciamento.

Recapitulando, cada requisito de software necessita ter uma identificação única, uma espécie de ID de identificação.

Não existem padrões bem formalizados sobre como determinar este ID de identificação, mas, algumas ferramentas de gerenciamento de requisitos, que veremos posteriormente, sugerem algumas identificações.

Hoje, lhes apresentarei o seguimento dos conceitos sobre gerenciamento de requisitos, abordando o conteúdo de relacionamento entre requisitos, fundamental para se conseguir efetivamente aplicar o gerenciamento de requisitos. Contudo, vale lembrar que se tratando de produtos de software, existem diversos tipos de requisitos funcionais e não funcionais e todos podem ser relacionados no processo de gerenciamento de requisitos. Para relembrar, revejam o post sobre O que são Requisitos de Software?.

Relacionamento entre Requisitos de Software:

Os requisitos de sistema possuem muitas relações entre si e entre informações relativas ao projeto. Em razão disso, quando são propostas modificações é preciso avaliar o impacto destas mudanças sobre os requisitos e sobre o projeto do sistema. Assim, a facilidade de rastreamento é importante e trata-se de uma propriedade da especificação dos requisitos que reflete na facilidade de se encontrar requisitos que são relacionados. Existem três tipos de informações básicas sobre a facilidade de rastreamento que podem ser mantidas (SOMMERVILLE, 2003):

-Rastreamento da Origem: vinculam os requisitos aos stakeholders que propuseram os requisitos. Quando é sugerida uma mudança nos requisitos é possível consultar os envolvidos na sua definição inicial para avaliação desta mudança;

-Rastreamento de Requisitos: vinculam requisitos dependentes entre si. Estas informações permitem avaliar quantos requisitos poderão ser afetados com a solicitação de mudança proposta, bem como a extensão das mudanças conseqüentes nos requisitos que podem ser necessárias;

-Rastreamento do Projeto: vinculam os requisitos aos módulos do projeto em que estes requisitos estão implementados. Estas informações são utilizadas para avaliar o impacto das mudanças nos requisitos, as propostas para o projeto e a implementação do sistema;

A representação das facilidades de rastreamento normalmente é realizada com o uso de matrizes que relacionam os requisitos aos stakeholders, os requisitos entre si e aos módulos do projeto. Utilizando de exemplo a representação da relação dos requisitos entre si, cada requisito será representado por uma linha e por uma coluna na matriz. Onde houver a dependência entre os requisitos ela seria apontada na intersecção entre a coluna e a linha, conforme FIGURA 1 (SOMMERVILLE, 2003).

FIGURA 1 – Matriz de Facilidade de Rastreamento (SOMMERVILLE, 2003)

Na FIGURA 1 são apresentadas letras para relacionar os requisitos entre si. A letra “U” ilustra que o requisito na linha utiliza os recursos especificados no requisito nomeado na coluna (SOMMERVILLE, 2003).

A letra “R” representa a relação fraca entre requisitos. Por exemplo, ambos os requisitos podem definir partes de um mesmo subsistema (SOMMERVILLE, 2003).

A matriz de facilidades de rastreamento pode ser utilizada quando um pequeno número de requisitos precisa ser gerenciado. Porém, se torna onerosa a sua utilização para manusear um grande número de requisitos. Para sistema com grande quantidade de requisitos, precisamos registrar as facilidades de rastreamento em um banco de dados de requisitos, onde cada requisito é explicitamente vinculado a requisitos relacionados. O impacto da mudança seria verificado através de recursos de visualização do banco de dados. Em razão disso é que se utilizam ferramentas CASE para realizar este apoio no processo de gerenciamento de requisitos (SOMMERVILLE, 2003).

Na terceira parte, pretendo lhes apresentar as técnicas efetivas de realização do rastreamento de requisitos. Aguardem!

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com/

Bibliografia:

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Minimizando Problemas com Requisitos – Parte 1

2009-11-11T15:51:00.000-08:00

No post anterior discutimos a respeito dos problemas comuns existentes com os requisitos de software.

Visando reduzir os problemas existentes com requisitos de software, gostaria de lhes apresentar uma série de posts que tratarão de conceitos e técnicas que podem ser aplicados para minimizar as divergências com os requisitos.

Hoje, gostaria de lhes apresentar uma primeira etapa de conceitos que aborda o Gerenciamento de Requisitos de Software e seus aspectos relevantes que devem ser considerados para iniciarmos a organização dos requisitos de software.

Gerenciamento de Requisitos de Software:

O gerenciamento de requisitos trata-se de uma abordagem sistemática para se obter, organizar e documentar os requisitos do sistema. Além disso, é um processo que possibilita manter um acordo entre o cliente e a equipe do projeto sobre a evolução das necessidades do sistema (LEFFINGWELL; WIDRIG, 2000).

O processo de gerenciamento de requisitos visa compreender e controlar as mudanças nos requisitos do sistema. Este processo é realizado juntamente dos demais processos de engenharia de requisitos. O planejamento deve ser realizado ao mesmo tempo em que os requisitos estão sendo levantados e o gerenciamento dos requisitos deve ser iniciado após ter um esboço do documento de requisitos (SOMMERVILLE, 2003).

O planejamento é a primeira etapa do processo de gerenciamento de requisitos. Estabelece o nível de detalhamento necessário para realizar o gerenciamento de requisitos (SOMMERVILLE, 2003).

Para realizarmos o gerenciamento de requisitos, precisamos estabelecer alguns aspectos básicos (SOMMERVILLE, 2003):

-Identificação dos Requisitos: Cada requisito precisa ser identificado de forma única para facilitar a realização de rastreamento entre requisitos. Basicamente, cada requisitos precisa ter um “ID” que o identifica e eles nunca deve se repetir;

-Processo de Gerenciamento de Mudanças: Trata-se de um conjunto de atividades que avalia o impacto e o custo das mudanças;

-Políticas de Facilidade de Rastreamento: Definem relações entre requisitos e o projeto de sistema que devem ser registrados e também como devem ser mantidos;

-Suporte de Ferramentas CASE: Como o processo de gerenciamento de requisitos envolve uma grande quantidade de informações, deve-se determinar uma ferramenta para facilitar o trabalho.

Na segunda parte, pretendo lhes apresentar como é realizado o rastreamento de requisitos de software.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com/

Bibliografia:

LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements: a Unified Approach. Indianapolis: Pearson Education Corporate Sales Division, 2000.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Problemas Comuns com Requisitos de Software

2009-10-21T18:20:00.000-07:00

Conforme visto anteriormente, no tópico sobre Engenharia de Requisitos, num ambiente de desenvolvimento de software estamos constantemente criando, mudando, adaptando e aperfeiçoando os softwares. Nosso objetivo é conseguir desenvolver um produto de software que atenda às necessidades dos clientes e as demandas de mercado.

Quando fizemos isto estamos realizando alterações nos requisitos do software. Lembrando que requisitos de software podem ser compreendidos como a capacidade do software que deve ser atendida pelo sistema para satisfazer o problema do usuário. (DORFMANN; THAYER, 1990).

As vezes não nos damos conta dos problemas que ocorrem quando realizamos os trabalhos de manutenções em requisitos de software, mas lhes garanto que é algo muito comum num ambiente de desenvolvimento de software.

Os maiores problemas relacionados ao processo de Engenharia de Software são apresentados nas etapas de levantamento e especificação dos requisitos:

Problemas de Escopo: as limitações do sistema são mal definidas ou o cliente especifica detalhes técnicos irrelevantes que confundem ao invés de esclarecer os objetivos gerais do sistema (SOMMERVILLE, 2003).

Problemas de Entendimento: Os clientes não estão certos das necessidades, não compreendem as capacidades e limitações de seu ambiente computacional, não tem pleno domínio do problema, dificuldades para expressar o que necessitam, omitem informações que acreditam ser óbvias, criar requisitos conflitantes ou especificam requisitos ambíguos ou impossíveis de se testar (SOMMERVILLE, 2003). No processo de especificação dos requisitos, os problemas mais comuns estão relacionados aos clientes e desenvolvedores, pois nem sempre o cliente entende os processos de software num grau satisfatório para auxiliar na produção da especificação de um requisito viável. Por sua vez, o desenvolvedor também nem sempre compreende a área de aplicação suficientemente para produzir a especificação de forma satisfatória (PAULA, 2001).

Problemas de Volatilidade: Os requisitos são modificados ao longo do tempo (SOMMERVILLE, 2003).

Além disso, também é um problema comum o cliente pedir mais do que pode ser disponibilizado, considerando as limitações inicialmente impostas pelo negócio (SOMMERVILLE, 2003).

Por fim, existe também o problema relacionado à etapa de Gerenciamento de Requisitos que em algumas situações deixa de ser aplicado, comprometendo o gerenciamento dos requisitos especificados e perdendo o controle sobre suas alterações. Conseqüentemente, se um requisito for modificado, não há como identificar quais os demais requisitos que podem ser afetados por esta modificação (SOMMERVILLE, 2003).

Para resolvermos ou pelo menos minimizarmos é que executamos trabalhos de Gerenciamento de Requisitos de pretendo lhes apresentar numa próxima postagem.

Cordialmente,

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

Bibliografia:

DORFMANN, Merlin; THAYER, Richard H. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.

PAULA, Wilson de Pádua Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Oportunidade de Trabalho

2009-10-20T16:43:00.000-07:00

O processo seletivo do Programa de Estágio Oi 2010 começará em outubro desse ano.

Estágio Oi - nível superior;

- Estágio na Oi não tem enrolação, não tem blá-blá-blá. É uma oportunidade para quem é confiável e direto para lidar com os outros, inteligente e espirituoso no dia a dia e tem inovação e ousadia no DNA;

- Na Oi, Estágio é para aprender e fazer acontecer. Você tá dentro ou tá fora?

Além do trabalho em uma área da Oi, o Programa de Estágio acompanha sua evolução e investe no seu desenvolvimento, tudo para ajudá-lo a pensar sempre fora da caixa;

INSCREVA-SE ATÉ O DIA 25/10 – www.oi.com.br/euquerotrabalharnaoi

O processo seletivo começará em outubro/2009.

Para ser Estagiário Oi, você precisa:

Estar matriculado em um dos seguintes cursos superiores:
- Administração
- Análise de Sistemas

- Ciências Contábeis

- Comunicação Social (PP, Jornalismo e Relações Públicas)

- Direito

- Economia

- Engenharia de Computação

- Engenharia de Produção

- Engenharia de Sistemas

- Engenharia de Telecom

- Engenharia Elétrica

- Engenharia Eletrônica

- Estatística

- Informática

- Marketing

- Matemática

- Processamento de Dados

- Psicologia

- Pedagogia

- Relações Internacionais

- Sistemas da Informação

- Ter previsão de formatura entre janeiro/2011 e janeiro/2012;

- Se virar bem em Informática;

- Ter o Inglês intermediário.

Oferecemos:

Durante os 12 meses de Estágio, prorrogáveis por mais 12 meses, os Estagiários de nível superior recebem uma bolsa-auxílio mensal e têm direito a benefícios extras: auxílio transporte, vale refeição, seguro de vida e plano de celular específico também.

Atenciosamente,

Oi / Clave Consultoria

Engenharia Reversa de Software

2009-10-03T09:48:00.000-07:00

Pessoal, dando continuidade aos conceitos que envolvem a melhora da Qualidade num processo de desenvolvimento de software, gostaria de lhes apresentar os conceitos sobre um trabalho muito importante praticado principalmente em software legados ou cujo desenvolvimento não foi concebido utilizando-se das melhores práticas. Trata-se da Engenharia Reversa de Software.

A variedade de problemas que envolvem manutenção de softwares cresce constantemente e as soluções não conseguem acompanhar esta evolução. Estes problemas ocorrem em virtude de código fonte e documentação mal elaborada, além da falta de compreensão do sistema (OSBORNE; CHIKOFSKY, 1990).

Além de correções de erros, é comum que os sistema sofram migrações para novas plataformas, ajustes para novas tecnologias de hardware ou sistema operacional, além de extensões para atender aos usuários. Normalmente, estas mudanças são realizadas sem haver preocupações com arquitetura geral do sistema, produzindo estruturas mal projetadas, documentações desatualizadas, lógica e codificações ruins. Conseqüentemente, dificultam a manutenção de um sistema (OSBORNE; CHIKOFSKY, 1990).

Quando um sistema torna-se difícil de ser mantido, instável, mas ainda contém grande utilidade, ele deve ser reconstruído. Isto é, a partir do sistema existente, a partir da análise do código-fonte, interface e ambiente, são abstraídas as suas funcionalidades e são construídos os modelos de análise e projeto do sistema. A realização deste processo é chamada de Engenharia Reversa de Software (PIEKARSKI; QUINÁIA, 2000).

O principal objetivo da Engenharia Reversa de Software consiste em auxiliar na compreensão da estrutura interna de sistemas complexos (PRESSMAN, 2001).

A aplicação da Engenharia Reversa consiste na análise de um programa de computador que permite representá-lo numa abstração mais elevada do que o código-fonte. Ou seja, é um processo de recuperação de um projeto a partir da análise de código-fonte e extração de abstrações de processo, banco de dados e interface. As ferramentas de engenharia reversa extraem informações do projeto de dados, da arquitetura e dos procedimentos para um determinado programa (PRESSMAN, 2001). A FIGURA 1 demonstra o processo de Engenharia Reversa.

Além disso, a Engenharia Reversa de Software possibilita a reorganização e modificação de sistemas de software existentes, parcial ou totalmente, para possibilitar uma manutenção mais fácil do sistema. Com efeito, é possível reduzir o risco do software, revisando o que foi desenvolvido anteriormente e corrigindo se necessário. Além do mais, o custo do trabalho de reengenharia, visando melhorar o software, é insignificante ao custo necessário para desenvolver um novo software (SOMMERVILLE, 2003).

FIGURA 1 - O Processo de Engenharia Reversa (PRESSMAN, 2001)

Bibliografia:

OSBORNE, P.W.; CHIKOFSKY, E.J. Fitting Pieces to the Maintenance Puzzle. IEEE Software, v. 7, n. 1, 1990, p. 11-12.

PIEKARSKI, Ana E. T; QUINÁIA, Marcos A. Reengenharia de Software: o que, por quê e como. Guarapuava: Departamento de Informática – UNICENTRO, 2000.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5^th ed. New York: McGraw-Hill, 2001.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com

MPS.BR

2009-09-22T17:19:00.000-07:00

Em outro post, apresentei os conceitos sobre os Modelos de Qualidade de Software, inclusive, citei alguns existentes mais contemporâneos, aplicados hoje em dia. Além disso, já fiz uma breve descrição sobre como é o modelo de Qualidade denominado CMMI.

Para relembrar, a Qualidade de Software pode ser compreendida como a capacidade, componente ou processo satisfazer determinados requisitos, visando atender às necessidades e expectativas dos usuários (IEEE, 1990).

Além disso, a Qualidade de Software abrange tanto a qualidade de produto quanto de processo de software (KALAIMAGAL; Srinivasan, 2008).

Existem fatores que afetam a Qualidade de Software que podem ser medidos para buscar atingir um patamar de qualidade.

Em razão disso, foram criados modelos de maturidade de software que visam atender as necessidades de qualidade de produto e processo de software, dentre eles o MPS.BR que iremos discutir a seguir.

O MPS.BR trata-se de um modelo de qualidade que baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços relacionados. Dentro desse contexto, o MPS.BR dividi-se em três componentes (SOFTEX, 2007):

- MR-MPS: Modelo de Referência;

- MA-MPS: Método de Avaliação;

- MN-MPS: Modelo de Negócio;

Assim, o MPS.BR estabelece um modelo de processos de software e um processo e método de avaliação de processos que dá sustentação e garante que o MPS.BR está sendo empregado de forma coerente com as suas definições. Além disso, o MPS.BR estabelece um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software (SOFTEX, 2007).

O MPS.BR foi desenvolvido baseado nos modelos ISO/IEC 12207, ISO/IEC 15504 e CMMI (SOFTEX, 2007).

É um modelo especificamente definido para ser aplicado nas empresas de software do Brasil e seu maior diferencial, por exemplo, com relação ao CMMI, é o custo.

Além disso, ele é segmentado um uma quantidade maior de níveis, tornando menos complicada a capacidade de a empresa atingir determinado nível de maturidade.

A FIGURA 1 apresenta os componentes do MPS.BR e suas relações com as metodologias de qualidade usadas como base para sua concepção.

FIGURA 1 - Componentes do MPS.BR (SOFTEX, 2007)

Da mesma forma que o CMMI, o MPS.BR também é subdividido em níveis de maturidade, compostos por processos e atributos de processo que os complementam (SOFTEX, 2007). A TABELA 1 apresenta os níveis de maturidade do MPS.BR.

TABELA 1 - Níveis de Maturidade do MPS.BR (SOFTEX, 2007)

Os atributos de processos são descritos da seguinte forma:

- AP 1.1: O processo é executado;

- AP 2.1: O processo é gerenciado;

- AP 2.2: Os produtos de trabalho do processo são gerenciados;

- AP 3.1: O processo é definido;

- AP 3.2: O processo está implementado;

- AP 4.1: O processo é medido;

- AP 4.2: O processo é controlado;

- AP 5.1: O processo é objeto de inovações;

- AP 5.2: O processo é otimizado continuamente.

Cordialmente,

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

Bibliografia:

IEEE, Institute of Electrical and Electronics Engineers: Standard Glossary of Software Engineering Terminology, IEEE, 1990.

KALAIMAGAL, Sivamuni; Srinivasan, Rengaramanujam. A Retrospective on Software Component Quality Models. Nova York, v. 33, n. 6, p. 1-9, 2008.

SOFTEX. Associação para Promoção da Excelência do Software Brasileiro. MPS.BR – Melhoria do Processo de Software Brasileiro: Guia Geral, versão 1.2. SOFTEX, 2007.

A Importância dos Requisitos de Software: Uma Abordagem Prática

2009-09-13T10:42:00.000-07:00

Em postagens anteriores, foram apresentados conceitos sobre requisitos de software, os diferentes tipos de requisitos, bem como o gerenciamento dos requisitos.

Nesta oportunidade, gostaria de discutir um pouco da aplicação prática dos requisitos, sobre quais os benefícios de ter um bom processo de levantamento de requisitos e também como proceder com os requisitos para que sua elaboração seja útil ao projeto que está sendo desenvolvido.

Aproximadamente, 60% das falhas de software e defeitos são resultantes de má gestão do software e de seus requisitos. Este percentual eu mesmo determinei através de um trabalho de pesquisa que realizei numa empresa de desenvolvimento de produtos de software.

Metade destas falhas poderiam ter sido evitadas se tivesse sido clara desde o início, qual era realmente a expectativa do usuário/cliente. Logo, chegamos ao consenso de que o trabalho de desenvolvimento foi bem feito, mas foi desenvolvido de maneira diferente do que era esperado. Novamente fizemos um link com a tradicional imagem abaixo que visa elicitar de maneira descontraída como é um processo de desenvolvimento de um requisito de software.

FIGURA 1 – Processo de Desenvolvimento do Requisito de Software (DAGNONE, 2009)

Vimos também que Requisitos de Software podem ser compreendidos como a capacidade do software que deve ser atendida pelo sistema para satisfazer o problema do usuário (DORFMANN; THAYER, 1990). Na prática, o que ocorre é que nem sempre o levantamento dos requisitos é claro, sendo até mesmo mal interpretado, dificultando ainda mais o trabalho de manutenção quando se descobre esta divergência num momento tardio.

Em razão disso, o ideal seria fazer um bom trabalho prévio de levantamento das necessidades, o que já minimizaria pela metade os problemas com requisitos entendidos de maneira inadequada. Porém, este trabalho precisa ser desenvolvido e ter a colaboração de todos os envolvidos na sua concepção: gerentes de projeto, analistas de negócio, analistas de sistemas, clientes e usuários finais.

Sabemos que escrever requisitos da maneira plenamente satisfatória leva tempo e exige prática, mesmo tendo atualmente uma série de ferramentas que auxiliam, não será da noite para o dia que se conseguirá atingir bons resultados. Para isto, a pessoa precisa ter clareza para descrever as necessidades, ser organizada e principalmente ter bons conhecimentos de programação, pois é preciso saber exatamente o que sua equipe de desenvolvedores podem fazer, além disso, é preciso ter certeza de que você fala a mesma linguagem deles. Além disso, é muito importante que a pessoa também tenha capacidade de lidar com outras pessoas, pois é preciso entrar em contato com clientes para descobrir o que querem, como querem, e conseguir traduzir isto para compreensão dos desenvolvedores.

Um problema bastante típico é que nem sempre os clientes sabem o que eles precisam, outros não tem capacidade de ter uma visão de um todo para formular sua necessidade, outros pensam que sabem demais, guardando o conhecimento para si e lhe passando as idéias erradas e outros não estão preocupados necessariamente com o atendimento de sua necessidade e sim se os seus encargos são devidamente depositados no final do mês.

Assim, há um grande desafio de conseguir convencer pessoas com diferentes perfis a cooperar, repassando-lhes a importância desta etapa de levantamento de requisitos. Contudo, se mesmo assim houver dificuldades para elicitar os requisitos, uma segunda alternativa seria usar sua empatia, ou seja, posicionar-se no lugar do cliente e tentar entender a sua necessidade por conta própria. De qualquer forma, este tipo de posicionamento também exige um bom conhecimento e prática.

Se houver um bom contato com o cliente para elicitação dos requisitos, procure manter este contato durante toda a duração do processo, inclusive, posicionando o cliente. Esta ação é importante porque necessidades podem mudar, o cliente pode se dar conta de algo que havia esquecido de mencionar ou que talvez não tenha explicado de maneira mais adequada para ser entendido. Em contrapartida, o responsável pelo levantamento de requisitos precisa estar ciente de que sempre deve estar à disposição para entender novamente as solicitações e repassar por todas novamente caso seja necessário, visando repassar o desenvolvimento de um requisito de maneira satisfatória.

Além do cliente, o setor de testes de software também precisa estar plenamente ciente e comunicado sobre os requisitos que estão sendo desenvolvidos, de preferência, desde o início dos trabalhos, pois eles é que vão desenvolver os trabalhos de testes de conformidade e anteceder alguns detalhes sobre o que poderia dar errado no requisito que foi desenvolvido.

Analisando atualmente, um dos maiores problemas da elicitação de requisitos é o tempo necessário para descrevê-los de maneira satisfatória, pois as vezes não se tem todo o tempo necessários disponível. Mas, é iminente que quando o desenvolvimento começa a ser trabalhado antes de completarmos os requisitos podemos causar uma série de problemas mais tarde, onde o custo para ajustá-los é o dobro do custo que seria se fosse verificado ainda na etapa de levantamento de requisitos.

Um processo de desenvolvimento termina somente quando o cliente recebe a versão final do produto de software e se declara satisfeito com o que fora implementado. Assim, quanto menos divergências houver com relação às expectativas do usuário, melhor para todos, pois menos desgaste será causado.

Outro problema que pode acontecer é o cliente sinalizar que necessita de mais um requisito, num momento já inadequado, quando o processo de desenvolvimento, por exemplo, já estiver sendo finalizado. Normalmente, quando isto ocorre, o trabalho e os custos para realizar mais este requisito são demasiadamente grandes para valer a pena desenvolvê-lo. Contudo, se você tiver um bom processo de levantamento de requisitos, conseguirá mensurar claramente ao cliente os custos da adição de mais este ajuste no produto de software, apresentando-lhe o efeito desta nova implementação, traduzindo para a linguagem do cliente. Por sua vez, o cliente pode acabar acatando sua decisão e optando por deixá-la para um próximo momento, mais adequado. Isto tudo faz parte da negociação do projeto com o cliente, mas um bom trabalho de levantamento de requisitos auxilia também nas negociações.

Existem inúmeras ferramentas, livros, conceitos e orientações que podem ser verificados e utilizados para conseguir realizar um bom trabalho/processo de levantamento de requisitos de software, dentre elas: IEEE software Enginering Collection, IEEE STD 830-1998, bibliografia citada neste artigo, CMMI, MPS.BR, dentre outras.

Espero que este artigo os auxilie a vislumbrar a importância da realização de um bom processo de levantamento de requisitos de software. É um esforço, nem tão grande assim, que vale muito apena em projetos de software.

Cordialmente,

Marcelo Schumacher

http://isosoftware.blogspot.com

Bibliografia:

DAGNONE, Donaldo M. How Projects Really Work (Version 1.5).Disponível em: <http://www.projectcartoon.com/cartoon/611>. Acesso em: 5 mar. 2009.

DORFMANN, Merlin; THAYER, Richard H. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.

Oportunidade de Trabalho

2009-09-10T09:45:00.000-07:00

A PROCEMPA (http://www.procempa.com.br/) está selecionando estagiários para:

JavaScript e php.

Até o 4º semestre R$ 4,38 p/hora
Depois do 5º semestre 4,86 /hora

Mais benefícios: VT, Refeição, Bolsa, Benefícios Medico e Dentário

Contato com alexandre.freitas@procempa.com.br

Falta de Atenção e Excesso de Confiança

2009-09-07T11:27:00.000-07:00

Diariamente procuramos sempre achar soluções e mais soluções para tentar resolver ou minimizar os problemas que temos no processo de desenvolvimento de software.

Apesar de existirem modelos de qualidade de software que apresentam uma série de diretrizes para resolver estes problemas, hoje gostaria de abordar aspectos bem pontuais e que fazem uma diferença significativa no processo de desenvolvimento de software: a falta de atenção e o excesso de confiança. Esta combinação junta é literalmente fatal no processo de desenvolvimento de software.

Na última semana, realizei uma capacitação de um dos softwares que trabalho. Apesar de termos um bom processo de desenvolvimento enfrentei algumas dificuldades, dentre elas:

- Versões anteriores do software não eram atualizadas automaticamente: problema gerado porque mudaram um script do processo de instalação do software;

- Determinado relatório simplesmente não era impresso, ocorrendo um erro no seu processamento;

- Outros relatórios exigiam que os parâmetros de entrada fossem preenchidos, mas não fazia nenhum tratamento ou apresentava alguma característica visual que deixasse claro que era necessário preencher seus valores antes de emitir os relatórios;

- Uma DLL (biblioteca) que contém 30% dos recursos do software ao ser acessada gerava uma exceção do tipo “Operação Ilegal”. Isto ocorreu porque um simples arquivo de código-fonte foi versionado incorretamente. Logo, ao compilar a biblioteca usava uma versão incorreta de fonte;

Modificaram scripts do banco de dados, sem testar, porque estavam confiantes que não ocorreria problema.

Implementaram um recurso que coletava uma informação para apresentar num determinado relatório, mas nem sempre a informação existia e não fizeram o devido tratamento condicional neste caso, gerando a exceção e impedindo que determinado relatório fosse gerado.

Foi atribuída a versão incorreta para um código-fonte, o que comprometeu a geração da versão.

Todos estes problemas foram gerados simplesmente por falta de atenção ou excesso de confiança. Como citei, esta combinação de fatores é fatal na geração de um software.

Por mais que se tente trabalhar esta questão ela sempre ocorre. O pessoal da equipe de desenvolvimento ganha confiança no trabalho e quando menos se espera um problema destes ocorre.

O que podemos fazer para evitar este problema? Eu tenho algumas sugestões:

- Padronizar processos de codificação e versionamento de código-fonte;

- Padronizar o processo de desenvolvimento e teste de software: nenhum recurso, por mais simples que seja, pode ser liberado sem ser testado pela equipe de Testes de Software;

- Disciplinar a equipe para seguir adequadamente o processo de desenvolvimento e testes, limitando problemas por falta de atenção;

- Orientar a equipe para evitar falta de atenção e combinar medidas disciplinares caso divergências sejam liberadas deliberadamente em virtude da falta de atenção;

É importante trabalharmos medidas que minimizem este tipo de divergência. Na prática, problemas causados por falta de atenção ou excesso de confiança são os mais comuns que resultam em bugs no ambiente do cliente.

CMMI

2009-08-30T18:55:00.001-07:00

Em outro post, apresentei os conceitos sobre os Modelos de Qualidade de Software, inclusive, citei alguns existentes mais contemporâneos, aplicados hoje em dia.

Para relembrar, a Qualidade de Software pode ser compreendida como a capacidade, componente ou processo satisfazer determinados requisitos, visando atender às necessidades e expectativas dos usuários (IEEE, 1990).

Além disso, a Qualidade de Software abrange tanto a qualidade de produto quanto de processo de software (KALAIMAGAL; Srinivasan, 2008).

Existem fatores que afetam a Qualidade de Software que podem ser medidos para buscar atingir um patamar de qualidade.

Em razão disso, foram criados modelos de maturidade de software que visam atender as necessidades de qualidade de produto e processo de software, dentre eles o CMMI que iremos discutir a seguir.

O CMMI é um modelo de qualidade baseado em processos de melhoria e trata-se de uma evolução de outros modelos como o CMM. Ele descreve características de processos eficazes e fornece às organizações os elementos essenciais para criar processos eficazes. Pode ser aplicado na orientação do processo de melhoria através de um projeto, uma divisão ou ser aplicado numa organização inteira (SEI, 2007).

O CMMI pode ser utilizado em atividades do processo de melhoria provendo:

-Uma coleção de melhores práticas a serem seguidas;

-Um framework para organizar e priorizar as atividades;

-Suporte necessário para coordenação de atividades multidisciplinares que podem ser necessárias para a construção de um projeto com sucesso;

-Meios de destacar e alinhar os objetivos do processo de melhoria organizacional com os objetivos da empresa;

O CMMI é dividido em níveis de maturidade, conforme FIGURA 1. Porém, em cada nível, existem subdivisões em áreas de processo, com exceção do primeiro nível (SEI, 2007).

Cada área de processo corresponde a um conjunto de atividades que, tomadas em conjunto, permite alcançar uma série de objetivos importantes para se obter uma melhoria do processo (SEI, 2007). Ver FIGURA 2.

FIGURA 1 - Níveis de Maturidade do CMMI (CITS, 2009)

FIGURA 2 - Categorias de Processos do CMMI (CITS, 2009)

Oportunidade de Trabalho

2009-08-25T16:35:00.001-07:00

Oportunidade de Trabalho

2009-08-25T16:27:00.000-07:00

Empresa Actix Consultoria e Desenvolvimento de Sistemas, de Novo Hamburgo, oferece vaga para desenvolvedor.

Descrição da vaga:

- Desenvolver sistemas web multi-banco (Oracle e SQL Server) utilizando o .net framework 3.5 através da ferramenta Visual Studio 2008 com linguagem C#

Requisitos:

- Experiência em desenvolvimento de aplicações web utilizando framework .NET 2.0 ou superior em linguagem C#, Visual Studio 2005/2008;

- Bancos de dados Oracle e SQL Server;

- Desenvolvimento em camadas;

- Inglês técnico

Conhecimentos em Delphi, VB6, ASP e/ou PHP, assim como banco de dados MySQL são diferenciais.

Residir preferencialmente na região do Vale do Sinos.

Interessados enviar currículo para lfschilling@actix.com.br

Engenharia de Requisitos de Software

2009-08-17T16:25:00.000-07:00

Em nosso dia-a-dia, no ambiente de desenvolvimento de software, estamos constantemente criando, mudando, adaptando e aperfeiçoando os softwares. Nosso objetivo é conseguir desenvolver um produto de software que atenda às necessidades dos clientes e as demandas de mercado.

Contudo, o ideal é que consigamos controlar estas modificações nos requisitos de maneira organizada.

A proposta da Engenharia de Requisitos de Software é justamente esta, apresentar diretrizes que abranjam todas as atividades necessárias para criar e manter as documentações de requisitos de software (SOMMERVILLE, 2001). Estas atividades consistem num conjunto de técnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto (PAULA, 2003).

A Engenharia de Requisitos é uma área da disciplina de Engenharia de Software.

A Engenharia de Requisitos permite entender o que o cliente necessita, analisando suas necessidades, avaliando as ações que devem ser executadas, negociando uma condição adequada, especificando a solução claramente, validando a especificação e criando os requisitos conforme são transformados em um sistema (DORFMANN; THAYER, 1997).

O processo de engenharia de requisitos pode ser dividido em sete funções distintas (PRESSMAN, 2001):

Concepção: consiste na compreensão básica do problema, compreender os envolvidos que esperam solução, verificar a natureza da solução, estabelecer a comunicação e colaboração entre cliente e desenvolvedor;

Levantamento: consiste na coleta dos requisitos de forma organizada;

Elaboração: ação de modelagem de análise que define o domínio do problema informacional, funcional e comportamental;

Negociação: consiste na negociação do engenheiro de requisitos com o cliente. Através de uma abordagem iterativa, requisitos são eliminados, combinados, modificados, priorizados de forma que alcance um grau de satisfação;

Especificação: trata-se do produto de trabalho do engenheiro de requisitos. Consiste num documento que descreve a função e o desempenho de um sistema baseado em computador e as restrições que conduzirão o desenvolvimento;

Validação: os produtos de engenharia de requisitos que foram desenvolvidos são avaliados quanto a sua qualidade. Consiste em examinar a especificação para garantir que os requisitos tenham sido declarados de modo claro, tendo inconsistências, omissões e erros identificados e corrigidos e que produtos de trabalho estejam de acordo com as normas estabelecidas para o processo, o projeto e produto;

Gestão dos Requisitos: conjunto de atividades que auxiliam a equipe do projeto a identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer momento, à medida que o projeto prossegue.

Assim, apresentamos os conceitos que abrangem a Engenharia de Requisitos de Software. Os modelos de Qualidade de Software (ISO, CMMI, MPS.BR, por exemplo) e os modelos de Processos de Software (RUP, por exemplo) fornecem um conjunto de ações que podem ser aplicadas sobre esta diretrizes para atingir os resultados esperados.

Bibliografia:

DORFMANN, Merlin; THAYER, Richard H. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.

PAULA, Wilson de Pádua Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5^th ed. New York: McGraw-Hill, 2001.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Oportunidades de Trabalho

2009-08-06T18:36:00.000-07:00

A TOTVS Saúde de Porto Alegre está selecionando:

- 8 Vagas para Desenvolvedor.Net
- 4 Vagas para Analista de Sistemas

Se você tiver interesse em alguma das vagas por favor envie o seu currículo para curriculos@gens.com.br, indicando a vaga de seu interesse no título do e-mail.

Oportunidades de Trabalho

2009-08-06T18:28:00.000-07:00

A ilegra, empresa brasileira que atua no fornecimento de soluções direcionadas à tecnologia da informação, no Brasil e exterior; através de serviços nas áreas de desenvolvimento de software e infra-estrutura, trabalhando em diversas tecnologias (Java, Oracle e SAP), atuando nas modalidades de consultoria, fábrica de projetos, outsourcing e offshoring, está selecionando

Telefonista/ Recepcionista: 1 Vaga
Pré-Requisitos: Cordial, Interessada, voz clara e português correto.Conhecimentos em informática para acesso à sistema de gestão, bem como envio de e-mails à clientes e fornecedores

DBA Oracle PL/SR: 1 Vaga
Pré-Requisitos: Experiência em administração de banco de dados Oracle. Fundamental conhecimentos em Unix e Linux, desejável conhecimentos application Server

Comercial PL: 1 Vaga
Pré-Requisitos:
- vivência em área comercial, conhecer técnicas de venda de serviço e consultoria;
- conhecer TI, deve ser vendedor de projetos e sistemas (não vendedor de hardware);
- pensar no negócio, conseguir captar oportunidade e trazer para a realidade da ilegra;
- ensino superior em curso;
- desejável inglês avançado

Dados e Contatos da Empresa:

Juliana Valente Schultz

Recursos Humanos

currículos@ilegra.com
Fone: 55 51 3212 8444

Rua washington luiz, 820 cj. 902/803

Centro poa rs brasil cep: 90010-460

www.ilegra.com

Oportunidades de Trabalho

2009-08-06T18:25:00.000-07:00

VIAFLOW contrata Desenvolvedor Java J2EE.

O candidato deve ser capaz de discutir e propor soluções arquiteturais.

REQUISITOS INDISPENSÁVEIS: - criar frameworks e modelos de implementação com melhores práticas; - produtividade elevada em J2EE; - bons conhecimentos de UML; - domínio de JSP, Javabean, SQL, HTML, JavaScript, Modelos MVC, J2EE, Design Patterns e Struts; - experiência profissional com Java de 02 anos.

REQUISITOS DESEJÁVEIS: - tecnologias de content management e workflow; - C++ ou outras tecnologias para integrações de aplicações com periféricos tais como scanner e webcam e JSF Rich Faces; - servidores de aplicação WebSphere e jBoss.

Interessados, enviar seu curriculo para curriculo@viaflow.com.br

Como ter e Manter uma Equipe Unida?

2009-07-24T21:23:00.000-07:00

Há alguns dias participei de uma palestra cujo objetivo era discutir conceitos de métodos ágeis, mais objetivamente, SCRUM. O palestrante foi o Sr. Daniel Wildt.

Foram apresentadas as premissas necessárias para se conseguir desenvolver softwares de forma ágil. O que me chamou a atenção foi justamente o fato de uma destas premissas enfatizar a existência de um bom trabalho em equipe. Ou seja, é preciso ter uma equipe conjunta, unida, centrada, participativa e que “vista a camiseta” em busca dos resultados.

Considerando esta premissa, gostaria de compartilhar experiências a respeito destacando-lhes alguns detalhes e alguns resultados atingidos pela equipe em que trabalho, onde no final apresento-lhes a conclusão desta analogia.

No local onde trabalho, tenho a oportunidade de liderar uma equipe que atualmente é composta por quatro desenvolvedores. Somos responsáveis por construir novos recursos para dois dos três produtos de software da empresa. Os softwares que desenvolvemos têm em torno de 35 mil clientes no Brasil.

Vejam que citei que desenvolvemos apenas novos recursos, não realizamos necessariamente correções de bugs ou customizações. Conseqüentemente, temos de estar sempre com a imaginação apurada, o senso crítico em alta, termos a devida empatia necessária para se colocar no lugar do cliente, dentre outros aspectos que o desenvolvimento de um novo recurso de software necessita para ser construído da melhor forma.

Outro aspecto importante a citar é que trabalhamos no formato de fábrica de software, ou seja, periodicamente é contratado o desenvolvimento de uma lista de determinados recursos novos. Não podemos atrasar a entrega destes recursos, pois isto afetaria diretamente aspectos econômicos esperados pela empresa.

Considerando este cenário, tenho a lhes dizer que nossa equipe tem um alto índice de produtividade, utilizando padrões burocráticos como o RUP para gerir as documentações do sistema e seguir todo um workflow até que um item possa ser efetivamente construído. Além disso, temos uma união exemplar, focada nos resultados, ou seja, “pegamos junto para o que der e vier” não importando os problemas, mas visando resolvê-los. Além do mais, dificilmente, há necessidade de realizarmos horas extras para atendermos às expectativas.

No primeiro trimestre do ano não conseguimos entregar alguns dos recursos, afetando o centro de custo da nossa equipe. Mas, no final de junho conseguimos reverter o quadro, finalizando as tarefas que ficaram pendentes do primeiro trimestre e finalizando as tarefas contratadas no segundo trimestre. Na verdade, faltou apenas uma atividade que não conseguimos finalizar os testes no prazo. O que nos permitiu alcançar este resultado foi justamente as características que citei no parágrafo anterior.

Uma união como está eu nunca vi nem mesmo nos jogos de futebol em que participo, observando os jogadores do mesmo time que o meu, mesmo valendo um campeonato. Na verdade, se fosse comparar com uma equipe esportiva, acredito que a seleção brasileira masculina de vôlei seria um bom comparativo.

Gostaria de lhes apresenta a atual equipe na foto abaixo:

Da esquerda para a direita: Marcelo Schumacher (eu), Letícia Pillar, Aaron Bock e Antonio Nei

Está faltando um integrante, o Joel Fernandes, que não pode estar presente quando tiramos esta foto. Mas, pretendo atualizar a foto em breve.

Parênteses, eu particularmente tenho muito orgulho destas pessoas e é uma honra poder representá-los.

Aí vem a pergunta, “como ter e manter uma equipe unida em busca dos resultados?”

Algumas das respostas eu sei lhes dizer pontualmente, outras respostas é apenas minha opinião e que eu acredito que faça com que nossa equipe tenha este diferencial.

Primeiramente, é obrigatório ter um bom ambiente de trabalho, silencioso, arejado te tal forma que não se passe calor, nem frio. Também é preciso dispor de bons equipamentos, de uma boa conexão de internet. Além disso, não devemos economizar em recursos que afetam fisiologicamente e psicologicamente as pessoas: deve ter água, banheiros e ambientes bem limpos, iluminação adequada e, se possível, o tradicional café porque ninguém é de ferro.

Ainda tratando do ambiente, convém que todas as pessoas que trabalham neste ambiente tenham uma boa relação, mesmo que profissional. Uma boa relação entre as pessoas também faz o ambiente ser propício para a execução dos trabalhos. Todas as semanas, o pessoal da empresa combina um futebol ou um almoço entre todos nas sextas-feiras e isto é muito bom para manter a boa relação.

Outro aspecto relevante é prover um bom trabalho de liderança. Para isto, uma equipe precisa ser ouvida e não mandada, devem ser realizadas reuniões periódicas que permitam a integração e o diálogo entre todos, alinhando-os sobre como estamos com relação aos resultados esperados e decidindo em conjunto as ações que podemos tomar para alcançar os resultados.

Tratando-se da equipe, deve-se prover encontros informais (Happy Hour) que permita ainda mais a integração entre as pessoas, principalmente para se conseguir conhecer as diferenças entre o profissional e a pessoa que convive com você no dia-a-dia. Conhecer a pessoa que existe no profissional é importantíssimo para você relevar certas atitudes ou ações que talvez não lhe agradem, mas que são características do profissional que existe nesta grande pessoa.

Além disso, é preciso trabalhar a equipe com um espírito de esportista. O líder tem que esforçar-se para sempre estar bem humorado e levantar o astral do pessoal. O líder precisa ser exemplo de trabalho e sua postura deve ser precisa, pois ele não pode falhar com a equipe e precisa ser sincero acima de tudo. O líder ampara, orienta, questiona, reconhece e vibra com sua equipe! O líder precisa representar a equipe com energia e acreditando que sempre alcançarão os resultados, não importando o cenário e esta impressão precisa ser claramente passada ao time. Conseqüentemente, a equipe cativa-se e com certeza terá orgulho de ser um time.

Prover a união dos profissionais, principalmente os da área de TI, necessita de um pouco de descontração, pois o trabalho é realmente pesado em certas circunstâncias. Logo, buscamos ter um clima descontraído, com censo de liberdade, lembrando das responsabilidades. Não exigimos nada além dos resultados e evitamos a cobrança excessiva. Algo que incomoda as pessoas é você diariamente perguntar “como está aquela tarefa?”. Passe a tarefa ao profissional, estipule uma data, diga que se tiver dúvidas pergunte e deixe a pessoa respirar e fazer a tarefa. Se num determinado dia você vê que o profissional não está dando a devida atenção à atividade, deixe-o, pois talvez não esteja num melhor dia, dê-lhe uma chance, pois ele sabe do prazo e da responsabilidade que tem e você precisa ter confiança nele. "Confiança" é uma das chaves do segredo para se ter uma boa equipe. Para ver como estão as tarefas, marque reuniões em conjunto com a equipe e alinhe os status das atividades entre todos. Nestas reuniões será possível verificar como anda o desenvolvimento e o cumprimento das responsabilidades de cada um, inclusive, antecipando possíveis “gargalos” que permitam a todos sugerir a devida ação em conjunto para eliminá-los. A equipe se considera útil podendo participar das decisões e não apenas codificando o que lhes pedem.

A união entre os membros da equipe precisa ser trabalhada. Para isso, é preciso promover e incentivar o diálogo entre as pessoas para que juntas busquem a solução de um problema. Uma das ações que tomamos e que nos geraram excelentes resultados foi restringir o acesso à internet. Temos excelentes profissionais à nossa volta que poderíamos aproveitar para aprender diariamente com eles, mas tendo a Internet a nosso alcance é muito fácil acessar o Google e ver qual a solução para um problema, apesar de nem sempre ser a melhor solução. Alguns podem defender a idéia de que fóruns são importantes ferramentas que a web provê, mas quantos de nós não se deparam com perguntas banais que o colega do lado lhe responderia em segundos? Eu parei de responder fóruns por isso. Você acessa a parte “perguntas avançadas” mas sempre tem alguém que posta uma pergunta que para ele é enquadrada como avançada e para os demais não é.

Por fim, e não menos importante, é o reconhecimento das pessoas. Quando uma equipe ou até mesmo alguém específico realiza um trabalho exemplar, isto precisa ser reconhecido pessoalmente. Não estou falando de aumento de salário, pois isto motiva o profissional por um mês. Me refiro a elogiar pessoalmente o trabalho que foi desenvolvido pelo profissional ou pela equipe e, dependendo das circunstâncias, divulgar este trabalho aos coordenadores das outras equipes da empresa ou das outras áreas da empresa, publicar na intranet. Em suma, promover este profissional ou determinada equipe pelo excelente trabalho que foi desenvolvido.

Pessoal, espero que o compartilhamento desta experiência e deste ponto-de-vista seja relevante para ao menos fazê-los pensar a respeito da gestão de sua equipe e se está mesmo aplicando os métodos mais adequados para manter a sua equipe unida e juntos buscarem a qualidade do produto de software e do processo de software.

Confiança de Software! Alguém pensa nisso?

2009-07-13T19:26:00.000-07:00

Nesta semana, estive pensando, porque alguns trabalham tanto no desenvolvimento de determinado Software e ainda chegam à conclusão de que os clientes só reclamam do sistema?

Pensei em diversas questões de qualidade visando mudar este cenário. Será que melhorias no processo de software ajudariam? Talvez sim! Mudanças no software, visando melhorar sua arquitetura, sua interface, sua segurança na gravação de dados? Talvez resolvesse também! Mas, talvez estas melhorias seriam melhor assimiladas por novos clientes, não acham? Ou será que os antigos clientes “reclamões” deixariam de ser assim?

A questão que gostaria que pensassem é que boa parte dos clientes não reclamam ou questionam por acaso. Não estou querendo defender necessariamente os clientes, pois realmente existem alguns que exageram. Mas, boa parte dos clientes que questionam, fazem isso com razão e não tenho dúvidas disso. O cliente conquista está razão quando perde a confiança no software.

A confiança de um sistema é uma propriedade que equivale à sua integridade. A integridade, no ponto de vista do usuário, consiste em operar o sistema, ter os resultados esperados e não “falhará” na sua utilização normal (SOMMERVILLE, 2003). Aí está o problema, pois a confiança é uma informação qualitativa e pode variar sua ponderação de um usuário para outro.

A confiança possui quatro dimensões:

FIGURA 1 - Dimensões da Confiança

Um bom índice de confiança só pode ser alcançado à custa do desempenho do sistema. Isto é, um software confiável inclui, por exemplo, código extra, muitas vezes redundante, para realizar a verificação necessária e possibilitar a recuperação a partir de falhas que possam ocorrer. Isto reduz o desempenho e aumenta a quantidade de armazenamento do sistema. Contudo, existe uma série de razões pelas quais a confiança é, em geral, um atributo mais importante que o desempenho (SOMMERVILLE, 2003):

1) Geralmente, os sistemas que não são confiáveis não apresentam segurança e em razão disso não são utilizados. Os usuários se recusam a utilizar um software que não for confiável. Se forem forçados a utilizar, eles boicotam o uso e armam uma verdadeira armadilha para retirar este software de seu dia-a-dia. Conseqüentemente, o cliente apenas aguarda o término do contrato e muda para outro, ainda mais nos dias de hoje onde há diversos fornecedores. O pior é que os usuários tendem a se recusar a utilizar outros produtos da empresa que produziu esse sistema. Logo, não adianta lançar um produto completamente novo se a confiança do usuário está afetada, pois fica marcado o produto e a própria empresa;

2) Os custos da falha de um sistema podem ser enormes. Imaginem se um software de controle de reator nuclear apresentar uma falha? Ou então, um software de controle de tráfego aéreo? O custo por uma falha num destes sistemas pode ser muito maior do que um simples bug a ser corrigido;

3) É extremamente difícil readquirir a confiança. Uma vez perdida a confiança com um cliente, o custo para readquiri-la e imensurável. Você pode ajustar um sistema ineficiente, mas uma vez não sendo confiável, melhorias serão de certo modo irrelevantes, pois o usuário considerará que o restante do sistema possui esta mesma ineficiência;

4) Freqüentemente, é possível compensar a falta de desempenho do sistema. Às vezes, os usuários podem adequar seu trabalho para atender a um sistema com desempenho inadequado. Todavia, uma falha na confiança geralmente surpreende o usuário. O software não confiável pode violar o sistema e os dados do usuário, sem aviso, e pode falhar, trazendo conseqüências sérias, que somente se manifestarão posteriormente;

5) Sistemas não confiáveis podem causar a perda de informações. É muito dispendioso coletar e manter dados. Algumas vezes, os dados são mais importantes do que o próprio sistema computacional. É preciso empregar muito dinheiro e esforço para duplicar dados valiosos e preservá-los, para que não sejam corrompidos.

A confiabilidade de um produto é influenciada pelo processo de software que leva ao desenvolvimento deste produto. Mas, como já foi dito, a confiabilidade é uma propriedade qualitativa e não pode ser medida, pois realmente é subjetiva e varia de um usuário mais rigoroso de outro menos rigoroso (SOMMERVILLE, 2003).

De qualquer forma, para minimizarmos que nossos clientes percam a confiança nos nossos softwares, temos de sempre tentar fazer o melhor possível no que tange a melhoria de sua qualidade, seja por ajustes no processo de software, no momento da codificação, na construção da arquitetura, das interfaces, dentre outras.

Como já foi dito, reconquistar a confiabilidade é algo muito difícil. As vezes, é melhor você partir para outra do que tentar remediar ou então, torcer para o usuário querer partir para outra antes e você conseguir dialogar novamente com o cliente e com seu novo usuário, já apresentando um software mais confiável.

Não se pode ganhar todas, mas há recursos suficientes hoje em dia que realmente nos permitem melhorar a qualidade e diminuir a desconfiança gerada para os usuários.

Referências Bibliográficas:

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Qualidade de Software

2009-07-09T16:14:00.001-07:00

Muito se discute sobre a necessidade dos softwares terem maior qualidade. Hoje em dia, em virtude da Web, da necessidade de troca de informações, da segurança das informações, da necessidade de garantir que as informações estão sendo tratadas da maneira correta e com grande agilidade, vem sendo cada vez mais exigido dos Softwares que agreguem a máxima qualidade possível.

Anteriormente, preocupava-se em garantir uma maior qualidade de software para maiores clientes, ou clientes que representavam grande expressão financeira para a empresa que produzia o software. Atualmente, não importa o tamanho do cliente, pois a grande quantidade de ofertas de software e o próprio mercado estão encarregando-se de exigir esta maior qualidade. As empresas de software travam batalhas diárias para conseguir ficar até mesmo com o menor cliente existente.

Assim, através deste post tento descrever conceitualmente o que se entende por Qualidade de Software e o que vem sendo criado para tentar melhorar a Qualidade de Software.

A qualidade de software nada mais é do que a capacidade de um sistema satisfazer determinados requisitos, visando atender às necessidades e expectativas dos usuários (IEEE, 1990).

Entretanto, a qualidade de software não consiste apenas em avaliar se o produto de software atende às expectativas, mas também avaliar o processo de software.

O processo de software trata-se de um conjunto de atividades, pré-definidas, onde o resultado de sua execução gera o produto de software.

Assim, para cada situação, devem ocorrer medições para compararmos o software e o processo de software a algum valor para atingirmos um patamar de qualidade (PRESSMAN, 2001).

Os aspectos mais importantes que devem ser avaliados num software são: suas características operacionais, sua habilidade de passar por modificações e sua adaptação a novos ambientes.

Em razão destas necessidades é que foram criados os famosos modelos de maturidade de software. Atualmente, ouvimos falar muito de CMMI e MPS.BR, mas, outros anteriores que inclusive serviram como base para criar o CMMI e o MPS.BR são: ISO/IEC 9126, ISO/IEC 15504, ISO/IEC 12207, CMM, CMMI e MPS.Br (KALAIMAGAL; Srinivasan, 2008).

Cada um destes modelos de maturidade, também conhecidos como Modelos de Qualidade, possuem algumas particularidades importantes que auxiliam na busca da qualidade do processo e do produto de software. Alguns destes modelos chegam a ter recursos conteúdo suficiente até mesmo para orientar sobre como realizar as determinadas mudanças no processo de software e no produto de software para melhorar as suas qualidades.

Em breve, pretendo postar maiores detalhes sobre cada um destes modelos de maturidade e qualidade de software

Referências Bibliográficas:

IEEE, Institute of Electrical and Electronics Engineers: Standard for Software Configuration Management Plans, IEEE, 1990.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th ed. New York: McGraw-Hill, 2001.

KALAIMAGAL, Sivamuni; Srinivasan, Rengaramanujam. A Retrospective on Software Component Quality Models. Nova York, v. 33, n. 6, p. 1-9, 2008.

Processo de Software

2009-07-04T07:48:00.000-07:00

Atualmente, ouvimos falar de diversos Modelos de Qualidade de Software que consistem numa verdadeira “sopa de letrinhas”, dentre eles: ISO 9126, ISO/IEC 12207, ISO/IEC 15504, CMM, CMMI, MPS.BR, dentre outros. Pretendo discutir mais detalhadamente cada um destes modelos em outros posts.

Apesar de cada modelo ter suas particularidades, existem alguns princípios e conceitos básicos que todos eles devem abranger. Em outras palavras, estes conceitos tratam-se de abstrações que servem como base para qualquer Modelo de Qualidade de Software.

Uma destas abstrações corresponde ao conceito de Processo de Software.

O Processo de Software trata-se de um conjunto de atividades e resultados que geram um produto de software. Entretanto, não existe um processo ideal e cada organização pode adaptar o processo de desenvolvimento para adequar-se à sua necessidade. Contudo, existem algumas atividades fundamentais comuns a qualquer processo de desenvolvimento de software, por mais adaptado que seja:

- Especificação de Software: Aborda a definição da funcionalidade do software e as restrições em suas operações;

- Desenvolvimento de Software: Consiste na construção do software atendendo às especificações;

- Validação do Software: Corresponde a verificar se o software atende o que o cliente deseja;

- Evolução do Software: O software deve seguir uma evolução para atender às necessidades mutáveis do cliente.

Estas atividades podem ser descritas em diferentes níveis de detalhamento, sendo organizados de maneiras distintas nos variados processos de software existentes. Além disso, os prazos das atividades podem variar, bem como os resultados de cada atividade (SOMMERVILLE, 2001).

A partir do conceito de Processo de Software, foram criados modelos de desenvolvimento genéricos que definem uma estrutura de processo. Todavia, não se consegue ter um nível de detalhamento de atividades específicas. Os modelos genéricos existentes são:

- Modelo em Cascata: Este modelo representa as fases de especificação, desenvolvimento, validação e evolução separadas por processo. Assim, para cada novo item a ser desenvolvido no software é preciso concluir etapa por etapa, seguindo a hierarquia dos processos para finalizar o desenvolvimento. Ou seja, surge uma nova demanda de desenvolvimento, você precisa primeiramente concluir toda a especificação para partir ao desenvolvimento, depois concluir todo o desenvolvimento para partir para a validação e assim por diante;

- Desenvolvimento Evolucionário: Neste modelo há uma intercalação entre as atividades de especificação, desenvolvimento e validação. A proposta consiste em desenvolver um modelo inicial do software, bem básico e desenvolvido rapidamente. Após, com base em mais informações coletadas ou recebidas, de clientes, de mercado, de negócio, incrementa-se este modelo inicial para então atender às necessidades e concluir o produto de software. Seria como iniciar o desenvolvimento do software e ir melhorando-o gradativamente;

- Desenvolvimento Formal: Este modelo consiste na produção de um software a partir de métodos matemáticos que praticamente validam cada item a ser desenvolvido de maneira formal. Isto é, para cada desenvolvimento realizado é preciso provar matematicamente o seu resultado. Este tipo de modelo é normalmente utilizado para softwares que necessitam de precisão, por exemplo, software de equipamentos eletrônicos que realizam incisões cirúrgicas em pacientes, onde o corte deve ser preciso para não comprometer a saúde do paciente. Softwares militares, nucleares, também são desenvolvidos utilizando este modelo;

- Desenvolvimento Orientado a Reuso: Como o próprio nome sugere, o modelo orientado a reuso consiste na utilização de componente reutilizáveis. O processo de desenvolvimento se concentra na integração destes componentes em um sistema, ao invés de ter de reescrevê-los para cada nova funcionalidade a ser implementada. Trata-se de uma modelo amplamente utilizado nos dias atuais, servindo como base do desenvolvimento orientado a objetos;

Avaliando estes modelos básicos conseguimos agora facilmente relacioná-los aos padrões de Qualidade de Software citados no início deste post. Além disso, fica evidente que estes conceitos, já existentes desde o início dos anos 90, serviram como base para modelos de processo de desenvolvimento que utilizamos atualmente.

Referências Bibliográficas:

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Oportunidade de Trabalho

2009-07-04T06:40:00.000-07:00

A e-core está selecionando pessoas com o perfil descrito abaixo:

- Experiência em desenvolvimento Java, (mínimo 03 anos);
- Conhecimento do Orientação Objetos, Arquitetura de SW e Design Patterns;
- Conhecimento de Frameworks Java (Spring, Struts, Hibernate, etc.);
- Conhecimento Servlets, JSP e EJB;
- Conhecimentos avançados de SQL Queries;
- Experiência na codificação do software baseado na arquitetura UML;
- Inglês avançado.

Interessados enviar curiculo para cintia.nunes@ecore.com.br

A empresa fica em Porto Alegre. Maiores informações sobre a empresa http://www.ecore.com.br/.

Dia-a-Dia: Release do Release = Desgastes

2009-06-30T18:59:00.000-07:00

Estou publicando aqui um tópico especial que consiste em relatos do dia-a-dia ocorridos com equipes de desenvolvimento de software, independente de empresa e com quem ocorreu. Poderei relatar algo do meu dia-a-dia, bem como relatos de amigos, colegas ou participantes do blog. Este tipo de tópico será freqüente e o intuíto é trocarmos experiências.

Fiquei sabendo de uma situação que ocorre seguidamente em nossos ambientes de desenvolvimento de software e achei interessante compartilhar. Trata-se de um ocorrido que gostaria de descrever a vocês.

Durante um mês inteiro, foi realizado um trabalho em conjunto com um cliente que consistia em realizar ajustes em dois softwares para contemplar um processo de integração entre de diferentes fornecedores. Em outras palavras, o cliente pedia, os analistas dos dois aplicativos entendiam, os desenvolvedores faziam. No final de cada dia, era enviado um release ao cliente com as devidas correções.

Contudo, o teste funcional ficou a encargo do cliente. Resultado? No outro dia pela manhã o cliente relata uma série de incorformidades que não atendiam o que ele havia solicitado. Tão logo os desenvolvedores sabiam do ocorrido, corriam para corrigir e liberar mais um release ainda pela manhã. Ou seja, o velho "release do release".

Além do problema de passar uma resposabilidade que um cliente não tem a mínima capacidade de assumir e até mesmo de assimilar, proceder destas forma deu margem para o cliente pedir o que ele achava que tinha que mudar em ambas as aplicações para atender todo o processo de integração, até mesmo meros relatórios que buscam informações. O cliente alegava que tais informações deveriam constar nos relatórios porque a integração as trafegava.

Ainda por cima, ocorreu muito do cliente solicitar uma integração, ela ser realizada da maneira que ele solicitou e quando o release chegou lá a segunda coisa que ele informa é que não está como ele havia explicado que queria. A primeira coisa era "bom dia". E ainda ocorria de o cliente assumir que pediu desta forma mesmo, mas que havia se enganado e agora as empresas, como meras fornecedoras, tinham de retomar os trabalhos e ajustar o software. senão o cliente nem as pegava. Isto vai de encontro a um post que fiz anteriormente e que trata do Gerenciamento de Requisitos de Software.

Em razão disso, fica envidente que houve uma grande furada aqui ao envolver um cliente para resolver problemas de dois produtos distintos. Ocasionou problemas de produto, desgaste das equipes de desenvolvimento, desgaste do cliente, mudanças de escopo constantes, má definição do que realmente precisaria ser feito, dentre outros fatores.

Um cliente só deve participar de um processo de desenvolvimento em dois momentos: para dar o aceite no que será feito e para avaliar os resultados após os testes de software.

Abraço,

Marcelo Schumacher

Por onde iniciamos a cuidar da Qualidade do Software? "Engenharia de Software"

2009-06-30T18:13:00.000-07:00

Não há como tratarmos de Qualidade de Software sem abordarmos uma das principais áreas cujos resultados das aplicações de seus conceitos influenciam diretamente na qualidade do software que está sendo desenvolvido.

Em razão disso, gostaria de lhes apresentar os conceitos básicos da Engenharia de Softwares que nos levam a vislumbrar as etapas de um processo de desenvolvimento onde ela influencia.

A engenharia de software é uma área da Engenharia que trata das características de produção de software, desde as etapas iniciais, onde o sistema é especificado, até a sua manutenção, após já estar sendo operado (SOMMERVILLE, 2003).

Além disso, a engenharia de software caracteriza-se por aplicar uma abordagem sistemática, disciplinada e mensurável para o desenvolvimento, operação e manutenção de softwares (IEEE, 1993).

A engenharia de software é necessária para evitarmos o caos no processo de desenvolvimento de software, através da aplicação de princípios científicos, métodos, modelos, padrões e teorias que possibilitam gerenciar, planejar, modelar, projetar, implementar, medir, analisar, manter e aprimorar um sistema de software (PETERS, 2001).

Em razão disso, compreende-se que a engenharia de software é dividida em camadas, focando na qualidade do software, conforme mostra a FIGURA 1 (PRESSMAN, 2001).

FIGURA 1 – Engenharia de Software em Camadas (PRESSMAN, 2001)

Considerando a FIGURA 1, cada etapa é preenchida por um conjunto de ações relacionadas que produz um produto importante de engenharia de software. Estas ações fornecem as técnicas necessárias para a construção de softwares, pois contemplam um conjunto de tarefas que incluem comunicação, análise de requisitos, modelagem de projeto, construção de programas, teste e manutenção. A base da engenharia de software é a camada de processo, pois mantém unidas as camadas de tecnologia, permitindo o desenvolvimento racional de software de computador (PRESSMAN, 2001). Considerando estes conceitos, nos próximos posts pretendo apresentar assuntos das áreas mais específicas da Engenharia de Software e que são mais visíveis no nosso dia-a-dia.

Referências Bibliográficas

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

IEEE, Institute of Electrical and Electronics Engineers: Software Engineering, IEEE Standard 610.12 – 1990, IEEE, 1993.

PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5^th ed. New York: McGraw-Hill, 2001.

Oportunidades de Trabalho

2009-06-29T20:11:00.000-07:00

A empresa TOTVS Saúde está contratando profissionais para trabalharem em Porto Alegre, nas seguintes funções:

- Desenvolvedor .NET (8 Vagas)

- Analistas de Sistemas (2 Vagas) (Área de Negócio: Gestão Hospitalar)

A empresa oferece:

- Vale Transporte;
- Vale Refeição;
- Plano de Saúde da UNIMED;
- Benefícios dentro do ambiente do TECNOPUC, pois uma das unidades da empresa está localizada neste complexo da PUC-RS (Pontífica Universidade Católica do Rio Grande do Sul), por exemplo, descontos em cursos;

Interessados podem enviar currículos para mim (marcelo.schumacher@gmail.com) que encaminharei a contatos da empresa.

O que são Requisitos de Software?

2009-06-29T19:50:00.002-07:00

Conforme visto no post anterior, requisitos de software nada mais são do que um conjunto de atividades que o software deve desempenhar, com suas limitações e restrições, além de características não ligadas diretamente às funções desempenhadas pelo software (SOMMERVILLE, 2003).

Quanto mais compreensível, precisa e rigorosa for a descrição de um requisito de sistema, maior será a proporção quanto ao grau de qualidade do produto resultante (PETERS, 2001).

Os requisitos de sistema são normalmente categorizados como funcionais, não funcionais ou requisitos de domínio. A seguir, abordaremos cada uma destas categorias.

Requisitos Funcionais:

Os requisitos funcionais tratam de funções que o sistema deve fornecer, como o sistema deve se comportar a estradas e a determinadas situações (PRESSMAN, 2001).

Em outras palavras, descrevem a funcionalidade ou serviço que se espera que o sistema forneça. Dependendo do tipo de software do requisito a ser descrito é possíveis criar subgrupos de requisitos funcionais, normalmente subdivididos como (SOMERVILLE, 2001):

- Requisitos Funcionais de Usuário: Normalmente descritos de um modo geral;

- Requisitos Funcionais de Sistema: Descrevem a função de sistema detalhadamente, suas entradas, saídas e exceções.

A especificação de requisitos funcionais deve ser completa e consistente. Isto consiste em deixar evidentes e definidas todas as funções requeridas pelo usuário. Além disso, não devem ter definições contraditórias.

Requisitos Não Funcionais:

Os requisitos não funcionais dizem respeito às restrições sobre os serviços ou funções do sistema. Por exemplo, restrição de tempo, restrição do processo de desenvolvimento, padrões, etc. (PRESSMAN, 2001).

Isto é, são aqueles requisitos que não dizem respeito às funções específicas fornecidas pelo sistema. Logo, estão diretamente relacionados a propriedades do sistema, como confiabilidade, tempo de resposta e espaço em disco. Podem definir restrições para o sistema, como a capacidade de dispositivos de entrada e saída relacionados e as representações de dados utilizados em um padrão de interface.

Contudo, requisitos não funcionais também dizem respeito ao sistema como um todo e não a características individuais do sistema. Em razão disso, podemos considerá-los mais importantes que requisitos funcionais individuais. Além disso, se houver falhas ao cumprir um requisito não funcional poderá tornar todo o sistema inútil.

Os requisitos funcionais normalmente surgem conforme a necessidade de usuários, de restrições de orçamentos, de políticas organizacionais, pela necessidade de interoperabilidade com outros sistemas ou devido a fatores externos, como regulamentações ou legislação, por exemplo. Assim, podemos classificar os requisitos não funcionais de diversas formas para poder organizá-los (SOMMERVILLE, 2003):

- Requisitos de Produto

---------- Requisitos de Facilidade de Uso;

---------- Requisitos de Eficiência;

-------------------- Requisitos de Desempenho;

-------------------- Requisitos de Espaço;

---------- Requisitos de Confiabilidade;

---------- Requisitos de Portabilidade;

- Requisitos Organizacionais;

---------- Requisitos de Entrega;

---------- Requisitos de Implementação;

---------- Requisitos de Padrões;

- Requisitos Externos;

---------- Requisitos de Interoperabilidade;

---------- Requisitos Éticos;

---------- Requisitos Legais;

-------------------- Requisitos de Privacidade;

-------------------- Requisitos de Segurança;

Requisitos de Domínio:

Os Requisitos de Domínio originam-se do domínio da aplicação do sistema, refletindo as características deste domínio (SOMMERVILLE, 2003). Podem ser funcionais ou não (PRESSMAN, 2001).

Se estes requisitos não forem atendidos satisfatoriamente, poderá ser impossível fazer a aplicação operar adequadamente.

Referências Bibliográficas

PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5^th ed. New York: McGraw-Hill, 2001.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

Porque Gerenciar Requisitos de Software?

2009-06-29T19:03:00.000-07:00

Os requisitos de software consistem num conjunto de características necessárias à aceitação de um software por parte do cliente, descrevendo quais atividades o software deve desempenhar, quais suas limitações e restrições, além de outras características não ligadas diretamente às funções desempenhadas pelo software. Logo, tratam-se da descrição das funções e restrições do sistema (SOMMERVILLE, 2003), seu fluxo de informações, comportamento e atributos (PETERS, 2001).

Em suma, o requisito de sistema fornece uma estrutura básica para o desenvolvimento de um software. Alguns dos problemas mais críticos do processo de desenvolvimento de software estão relacionados às etapas de especificação e gerenciamento dos requisitos. Conseqüentemente, temos requisitos que não atendem adequadamente às necessidades dos clientes e algumas das razões para este insucesso são: falta de processos de desenvolvimento bem definidos; requisitos de software não bem compreendidos e acordados; uso de técnicas inadequadas; falta de uma ferramenta de apoio adequada e a própria complexidade dos softwares a serem desenvolvidos (PAULA, 2001). Em relação aos requisitos, um problema bastante comum refere-se a sua instabilidade. A instabilidade está relacionada a alterações em requisitos já acordados ou inclusão de novos requisitos durante o processo de desenvolvimento. Essas alterações ocorrem, principalmente, em função de problemas durante a etapa de especificação do sistema a qual raramente é conduzida de forma adequada. O retrabalho é a conseqüência imediata da instabilidade dos requisitos, o que impacta diretamente no prazo do projeto e na qualidade do produto final (PAULA, 2001).

Entretanto, mesmo que a especificação de requisitos seja realizada de forma adequada é natural que ao longo do ciclo de vida do software sejam necessárias alterações nos requisitos do sistema em função da necessidade de manutenções corretivas e evolutivas (PRESSMAN, 2001). Por isso, é extremamente importante que todos os requisitos tenham sido adequadamente documentados e mantidos. É baseando-se na especificação dos requisitos que o profissional ou equipe que prestara a manutenção poderá minimizar os riscos de causar impacto não desejado em outras partes do sistema (SOMMERVILE, 2003).

Além disso, durante o desenvolvimento de softwares de grande porte e alta complexidade inevitavelmente teremos alterações nos requisitos. Nestes casos, podemos considerar que os requisitos são necessariamente incompletos durante o processo de desenvolvimento. O problema inicialmente levantando amadurece e acaba sendo compreendido com mais clareza durante o desenvolvimento, ocasionando a necessidade de alterações nos requisitos (SOMMERVILLE, 2003).

Assim, tão importante quanto à especificação adequada dos requisitos é realização constante de um eficaz processo de gerenciamento dos requisitos. O gerenciamento de requisitos visa compreender e controlar as mudanças nos requisitos de software, garantindo um melhor controle sobre estas mudanças e minimizando os riscos de impactos não desejados e não conhecidos (SOMMERVILLE, 2003).

A FIGURA 1 tem sido utilizada no mercado e na academia, pois ilustra de forma bem humorada os inúmeros problemas possíveis durante o processo de especificação e gerenciamento de requisitos:

FIGURA 1 – Possíveis problemas durante o processo de requisitos (DAGNONE, 2009)

Como ilustrado na FIGURA 1, muitos softwares que hoje são utilizados no mercado resultaram de projetos problemáticos nos quais nenhuma ou pouca documentação foi gerada. Conseqüentemente, é possível que a sua manutenção seja difícil e onerosa (PETERS, 2001).

Entretanto, estes softwares ainda são comercializados, representando grande parte da receita das empresas desenvolvedoras, e utilizados por muitos clientes que, após sucessivas atualizações e modificações, têm as suas necessidades atendidas.

Em razão disso, é extremamente importante que as empresas que realizam constantemente manutenção de software possuam todos os requisitos documentados e gerenciem efetivamente esses requisitos a fim de otimizar e qualificar o processo de manutenção garantindo, assim, maior qualidade e confiabilidade nas novas versões entregues aos clientes.

Referências Bibliográficas

DAGNONE, Donaldo M. How Projects Really Work (Version 1.5).Disponível em: <http://www.projectcartoon.com/cartoon/611>. Acesso em: 5 mar. 2009.

PAULA, Wilson de Pádua Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.

PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5^th ed. New York: McGraw-Hill, 2001.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

O Início

2009-06-29T17:47:00.000-07:00

Particularmente, sou um grande fã de Softwares cujo processo de definição e desenvolvimento contém uma preocupação com a Qualidade do Software. Esta Qualidade a que me refiro não está necessariamente relacionada ao que o usuário do software enxerga ou a não ocorrência de bugs para este usuário, mas sim à Qualidade de todo o processo de software, desde o levantamento de seus requisitos, sua definição, concepção, dentre outras etapas que compõem o software e seu ciclo de vida.

Assim, gostaria de poder usar este blog para compartilhar minhas experiências e de demais interessados que quiserem participar, sobre a área de Qualidade de Software. Além disso, pretendo postar pesquisas que realizo na área, sejam formais ou informais, ou qualquer outra informação que agregue conhecimento relevante sobre o assunto.

Também estarei disposto a ter um diálogo com os interessados e participantes, respondendo dúvidas, tirando dúvidas minhas também, auxiliando nos assuntos da área, aceitando críticas e sugestões. Em suma, todo este contexto visando a troca de informações relacionadas à área de Qualidade de Software

Gostaria que este blog um dia pudesse ser pelo menos um referencial sobre os assuntos de Qualidade de Software, sendo freqüentado e tendo seu conteúdo mantido por bons profissionais da área.

Cordialmente,

Marcelo Schumacher