Sucesso no desenvolvimento de software usando uma metodologia de desenvolvimento

Fonte: http://www.imasters.com.br/artigo/6566/des_de_software/sucesso_no_desenvolvimento_de_software_usando_uma_metodologia_de_desenvolvimento/

Sérgio dos Santos (e-mail) progamador e webdesigner – CPT – Centro de Produções Técnicas. Profissional especializado em Criação de sites e sistemas comerciais. Graduando em Sistemas de Informação pela FDV.

 As primeiras experiências dos programadores na construção de softwares mostraram que uma abordagem informal no desenvolvimento não era o bastante para se obter sucesso no processo. Projetos grandes e importantes estavam sem qualidade, com orçamento altíssimo e, além disso, sofreriam atrasos de anos. Por que, então, não usar uma metodologia de desenvolvimento de software para garantirmos uma qualidade no processo de desenvolvimento e também no produto final?

Nos anos 70, quando os gerentes de TI não tinham idéia de como desenvolver um software com qualidade, usando uma metodologia específica e também com uso de técnicas de engenharia de software, a idéia era de produzir softwares que fossem apenas eficientes. Porém, com o passar do tempo, essa visão ficou ultrapassada e, hoje em dia, fica claro que o desenvolvimento de software tem de gerar um produto que por si só seja eficaz, em tempo hábil, e com orçamento previsível.

Continuar lendo

Anúncios

Falha grave em Java abre qualquer PC para invasão

Fonte: http://tecnologia.terra.com.br/interna/0,,OI1762653-EI4805,00.html

Uma falha crítica e perigosa no Java pode colocar praticamente todos os computadores do mundo em risco. A falha, descoberta por pesquisadores australianos, é grave e pode levar a invasões em massa.

» Sun aposta em Java para TV no Brasil
» Virus para computador faz 25 anos

Segundo o site da ZDet Australia pesquisador Robert Lowe, do Australia’s Computer Emergency Response Team (AusCERT) alerta que qualquer um que possua o Java Runtime Environment (JRE) ou o Java Development Kit (JDK) está em perigo. “A exploração dessa falha é fácil e, portanto, atraente para os agressores porque mesmo que o usuário se lembre de atualizar seu navegador de Internet, normalmente ele se esquece de atualizar também os plugins chamados pelo navegador para renderizar tipos específicos de conteúdo”, completa Lowe, referindo-se ao Java e outros produtos como o Flash e o Real Player.

Muitos analistas estão alarmados. “O perigo aumenta a cada segundo”, afirmou Chris Gatford, um especialista em testes de penetração da empresa de segurança Pure Hacking. “É uma falha bastante significativa, que terá impacto considerável dependendo da velocidade com que os agressores produzam formas de explorá-la. A falha afetaria muitas e muitas organizações e usuários. Há Java em quase tudo: telefones celulares, PDAs e computadores pessoais. Além disso, a falha é independente de plataforma; qualquer navegador de Internet estaria vulnerável desde que invocasse um JRE com a falha”.

O site de segurança Security Focus também noticiou o caso, mas não confirmou por falta de provas de conceito. A AusCERT, entretanto, confirma a falha e recomenda aos usuários que atualizem suas versões do Java. A descrição completa da falha e instruções para atualização podem ser lidas no atalho dtmurl.com/b1b.

Análise de pontos de função e sua importância para projetos de desenvolvimento de software

Este artigo mostra de forma geral como é feita a medição de software através da técnica de Análise de Pontos de Função, onde são mostrados os principais processos de contagem de Pontos de Função e a importância que a medição de software tem para os projetos de desenvolvimento de software.

Link do artigo: http://br.geocities.com/lidimoncristiano/ArtigoAPF.pdf

Camadas JavaEE

Sobre o autor:
Marcelo Elias Del Valle (mvallebr@gmail.com) trabalha com Java e desenvolvimento de software em geral desde 1998, já tendo trabalhado em várias multinacionais relacionadas com o setor de TI em várias áreas, desde telecomunicações e área bancária até desenvolvimento de software científico. Marcelo é SCJP 1.4, tem SCEA parte 1 e superior incompleto em engenharia elétrica na USP. Usa seu raro tempo livre estudando processos de desenvolvimento de software e imaginando arquiteturas possíveis para jogos de computador. 

 

Quais são as camadas na arquitetura de referência JavaEE e o que significam

A arquitetura de referência J2EE define terminologias e conceitos muito úteis quando estamos definindo e discutindo arquiteturas de aplicações. Um dos conceitos mais básicos, que infelizmente parece ser pouco conhecido entre os profissionais J2EE, são as camadas de aplicação e alguns conceitos relacionados.

O objetivo desse artigo é dar uma visão geral sobre esses conceitos.

Pré-requisitos

Esse artigo requer muito pouco conhecimento técnico para ser lido, podendo inclusive ser interessante para gerentes ou outras pessoas de áreas não técnicas terem uma idéia do que significa desenvolvimento J2EE.

Arquitetura de referência JavaEE

Dentre as várias formas de classificar os tipos possíveis de arquiteturas de software, existe uma que as divide entre arquiteturas de sistema e arquiteturas de referência.

Arquitetura de sistema refere-se à arquitetura de um sistema específico, na qual são definidos diagramas de instalação, design, interfaces, classes, etc. É a especificação técnica de como o sistema vai lidar com requisitos não funcionais.

Continuar lendo

Estratégia para Entrevistas – LTI – Levantamento Técnico Inicial

Por Fabio Camara
MCP, MCSA, MCAD Charter, MCDBA e MCSD.NET. Escreveu os livros “Projetos com Windows DNA e .NET” e “Orientação a Objeto com .NET” dentre outros, editados pela Visual Books Editora. Pode ser contatado pela home page C# Br (http://www.csharpbr.com.br).

Fonte: http://www.linhadecodigo.com.br/artigos_impressao.asp?id_ac=916

Esse guia tem como objetivo esclarecer quais são as informações que devem ser extraídas das pessoas entrevistadas em um LTI – Levantamento Técnico Inicial.

Perfil dos entrevistados

Cada pessoa entrevistada tem uma visão diferente do sistema, logo devemos considerar que a forma de abordagem nas entrevistas será diferente, bem como as informações coletadas terão um valor diferente para o levantamento.

Sponsor:

É o responsável pelo negócio que o sistema se propõe a automatizar, geralmente é um gerente, diretor, coordenador ou supervisor de departamento ou área. Essa pessoa tem as informações em um nível gerencial e deverá descrever como o sistema irá contribuir para o negócio de forma estratégica, isto é, que informações o sistema deve disponibilizar em um nível estratégico.

Em alguns sistemas a preocupação do Sponsor pode ser aumentar a agilidade do departamento ou área e eliminar o trabalho manual – conceitos de automação – objetivando melhores e mais confiáveis resultados, porém sempre essa preocupação tem uma conotação estratégica dentro do seu trabalho.

Outra visão, ele(a) é a pessoa que, de alguma forma, está pagando pelo sistema, logo também é de seu interesse o tempo em que a solução será desenvolvida, os custos envolvidos e a qualidade do produto entregue. Muito provavelmente o Sponsor não é responsável só por uma área ou departamento, nesses casos será possível extrair dele, a nível corporativo, qual e á importância do sistema para a empresa.

IT-Manager:

Essa é a pessoa que conhece todo o parque tecnológico da empresa, as informações sobre tecnologias e plataformas existentes virão dessas pessoas, e direcionarão a decisão sobre como vai ser a arquitetura da solução proposta.

Todas as configurações de servidores bem como a topologia da rede e os ambientes (Desenvolvimento, Testes e Produção) existentes devem ser identificados nessa entrevista.

Também saberemos se a TI do contratante tem padrões a serem seguidos e quais são, se existe alguma metodologia e se deverá ser integrada com a nossa. Outro importante ponto é como está estruturada a equipe técnica e quem são as pessoas que estarão interagindo no processo de desenvolvimento, facilitando assim a identificação dos papéis necessários para o projeto em questão.

Usuário:

O usuário é a pessoa que realmente irá utilizar o sistema, que estará em pleno contato com o produto gerado. As entrevistas com o usuário, são chamadas requirements workshop e os produtos dessas reuniões serão: diagrama macro funcional, modelo de negócios, os esboços das telas do sistema e todos os requisitos não funcionais necessários ao sistema. Esta é uma sugestão genérica, dependendo da especialidade do projeto devemos incluir outros documentos ou extrair estas informações do pessoal de IT também.

Os esboços de tela irão garantir que você (analista) identificou boa parte da tamanho do sistema, sendo que nessa atividade de levantamento das telas, devemos ser bastante práticos, re-aproveitando o conhecimento de sistemas anteriores caso seja conveniente ou representando telas através de formulários que fazem parte do processo de negócio estudado.

Outros:

Para alguns casos, se fará necessária a entrevista com outras pessoas envolvidas com o sistema, por exemplo, no caso de um projeto de otimização e manutenção de um sistema, muito provavelmente entrevistaremos o programador que mantém o sistema atualmente, e tentaremos extrair dele, quais são as dificuldades enfrentadas durante as atividades de manutenção do sistema e os pontos de “gargalo” identificados. Estas pessoas recebem o nome de “stakeholder” que por definição seriam interessados ou pessoas que exercem influência no projeto. Particularmente considero extremamente salutar classificar todos os possíveis stakeholder antes de iniciar o projeto. Para saber mais sobre stakeholder visite o site http://en.wikipedia.org/wiki/Stakeholder

Perguntas Chave

Sponsor:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Quais informações estratégicas deverão estar disponíveis pela solução?

ü   Qual é a importância da solução para a empresa como um todo?

ü   Como a solução interage com outras aplicações do empreendimento?

ü   Qual a visão de longo prazo para o produto?

ü   Em quanto tempo seria ideal a conclusão do projeto?

ü   Qual é a previsão desse investimento? (levantar em unidade monetária ou horas de projeto)

IT-Manager:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Em que ambiente essa solução deverá funcionar?

ü   Qual é a abrangência geográfica e número de usuários que estarão utilizando a solução?

ü   Como é o parque tecnológico existente (Servidores, Desktops, Topologia da Rede, Internet)?

ü   Quais são os ambientes existentes na empresa (Desenvolvimento, Testes, Produção, etc…);

ü   Como serão as integrações entre os sistemas?

ü   Haverá migração de dados ? Em que estrutura estão esses dados?

ü   Existe alguma padronização a ser seguida e/ou algum artefato de sua metodologia que deverá ser gerado e entregue?

ü   Como esta estruturada a equipe de TI?

Usuário:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Que facilidades você espera do sistema?

ü   Qual informação do negócio é a mais difícil de processar (trabalho braçal, formato do dado, baixa navegabilidade em sistemas existentes)?

ü   Quais são as macro funcionalidades necessárias para os sistema?

ü   Quais são os atores que se relacionam com o sistema?

ü   Quais são as telas imaginadas para o sistema (modelo de negócio)?

ü   Como são as telas imaginadas para o sistema (esboços de telas)?

ü   Quais são as importações e exportações de dados necessárias para o funcionamento do sistema (detalhar o layout dos arquivos / fontes de dados)?

Outros:

Manutenções:

ü   Quais são as dificuldades de manutenção do sistema?

ü   Qual é a qualidade das estruturas do banco de dados?

ü   Qual é a qualidade do código fonte do aplicativo?

ü   A documentação do sistema é suficiente e compreensível?

ü   Como é a demanda (freqüência) de manutenção (corretiva, melhorias, legal)?

 ü   Quais são os pontos de “gargalo” do sistema atual?