Projeto de Software: Gerenciamento Eficiente

Prévia do material em texto

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SITEMAS
Portfólio Individual 5° Semestre
PROJETO DE SOFTWARE
Nome
Ana Carolina Teixeira dos Santos
Professores
Adriane A. Loper
Luis C. Perini
Marco I. Hisatomi
Paulo K. Nishitani
Veronice de Freitas
Gurupi – TO
2014
ANA CAROLINA TEIXEIRA DOS SANTOS
PROJETO DE SOFTWARE
Portfólio individual apresentado à UNOPAR – Universidade Norte do Paraná, como requisito parcial para obtenção do título de Analise e Desenvolvimento de Sistemas.
Profs.: Adriane A. Loper, Luis C. Perini, Marco I. Hisatomi, Paulo K. Nishitani, Veronice de Freitas.
Gurupi - TO
2014
Introdução
Sommerville (2003, p. 62) já comentava sobre o gerenciamento de um projeto de software onde que “O gerenciamento eficaz de um projeto de software depende de um planejamento acurado do andamento do projeto”.
	Hoje estamos em um mercado competitivo e corrido. Em todas as áreas no mercado de trabalho nós encontramos pessoas que possui pouco tempo sobrando para dedicar-se à qualidade do seu serviço. Se pararmos para simplesmente olhar um único ponto, enfatizando que devemos focar em apenas um único objetivo, com certeza iremos ser esmagados pela correnteza de turbilhões da vida em um mercado tão amargo. Deixando assim de lado a concentração e observação de longo prazo, para nos aderir a rápidas decisões e difíceis conclusões de ideias necessárias para a nossa realização pessoal e empresarial.
Sommerville (2003. P. 84) disse que “Em princípio, a especificação de requisitos funcionais de um sistema deve ser completa e consistente”.
	Não devemos simplesmente deixar as coisas passarem sem ao menos nos preocuparmos com o amanhã, e forcarmos apenas no hoje, pois precisamos nos precaver para não vermos nossos sonhos se desmoronarem na nossa frente como uma montanha de neve se despencando em meio ao vão. Para isso em um mercado de trabalho tão exigente e difícil existe meios de elaborar projetos mais confiáveis e de boa qualidade. Um projeto não é apenas uma palavra forte e admirável para ser dita e apreciada por profissionais e clientes, mas um caminho para ser seguido e fortemente enriquecido com o intuito de alcançar a tão sonhada qualidade.
“O sistema é uma ‘caixa-preta’ cujo comportamento somente pode ser determinado estudando-se suas entradas e saídas relacionadas” (Sommerville , 2003, p. 378, grifo do autor).
	O foco não está na perfeição, pois nós humanos já somos “perfeitos”, em cima disso indago que o objetivo está nas mudanças. Desde o inicio o mundo veio mudando, nós evoluindo, e o tempo passando, por isso é preciso perseverança e não “atirar pedras no escuro”. Nós sabemos que o tempo é curto, e demora muito para nos tornamos quem queremos ser. Devemos pensar no hoje, de tal forma que reflita no amanhã, sem perder o senso de espaço e realidade. Pois a dificuldade está naquilo que não foi planejado, afinal se algo pode ser previsto também pode ser concretizado!
Objetivo
O projeto deve ter um inicio, meio e fim bem definidos, não importando o tamanho ou a dificuldade do mesmo. Tarefas e atitudes devem ser pensadas, devem ser esculpidas, analisadas minuciosamente. Em um projeto simples, como a construção de uma página web, podemos usar etapas bem definidas e de fácil elaboração. Um ciclo de vida deve ser escolhido, pois precisamos saber como iremos proceder no decorrer do projeto, ou seja, o que faremos a cada processo. Podemos também construir uma WBS – Work Breakdown Structure com o intuito de analisar o que será feito em cada etapa do nosso ciclo de vida, mas com tudo isso é cobrado também um cronograma, pois os clientes querem datas definidas.
	O objetivo desse projeto é pesquisar e analisar um possível sistema em uma plataforma web que atenda as necessidades de uma empresa de locação de carros. Irei abordar o ciclo de vida adequado para consecução das etapas, com o objetivo de colher informações necessárias que se façam entender o que o cliente deseja. Com os requisitos já levantados construirei uma WBS para controlar as ações dos integrantes do projeto. Essa WBS irá auxiliar na execução de cada etapa do ciclo de vida. Um cronograma é preciso, pois datas são marcadas e precisão ser cumpridas. O cronograma é apenas para manter os analistas, gerente e programadores atualizados e equilibrados perante o tempo, afinal é necessário um foco, algo que mantenha a capacidade de cumprir prazos e horários. 
Estudo de Caso Locadora de Carros
Você-Aluga tem 26 filiais apenas nas capitais do Brasil. Cada agência é operada por um gerente e um grupo de agentes de locação que tratam das locações de carros.
A locadora aluga carros aos clientes previamente cadastrados. Caso o cliente não esteja cadastrado, esta atividade custodial é realizada, separadamente em outra atividade do sistema. Caso um carro, disponível, seja escolhido pelo cliente este é alugado, sendo registrada a data inicial junto ao aluguel. Para que o cliente possa alugar um carro, este não pode estar com dívida pendente. Os carros são descritos pela placa, ano, modelo, descrição, km, preço por km, situação (disponível, etc.), taxa diária, observações(informações gerais) e sua imagem. Os clientes são cadastrados pelo seu cpf, nome, endereço, telefone e dívida(reservado para registrar pagamentos pendentes).Quando o cliente devolve o carro, a situação do carro é mudada para “disponível”, o km é atualizado com o km atual do carro e um recibo é emitido, baseado nos kms rodados e nos dias em que ficou com o carro. Ainda na atividade de devolução é removido o registro do aluguel e, caso o cliente não possa pagar, a dívida do aluguel é registrada junto ao cliente.
Diagramas da UML
Exemplo: Casos de Uso
Objetivo:
Fazer locação de carros
Restrição:
Cliente não pode ter dividas pendentes
Atores:
Atendente
Entidade Custodial
Candidatos a Casos de Usos:
Cadastrar Cliente
Cadastrar Carro
VerificarDadosCliente
VerificarDividadoCliente
VerificarDisponibilidadeVeiculo
(Locar) EntregarVeiculo
Devolução) ReceberVeículo
EmitirRecibo
RegistrarDivida
Candidatos a Classe:
Veículos
Clientes
Divida do Cliente
Locação
Empregado
Atores:
Atendente: Faz o atendimento ao cliente da Locadora
Entidade Custodial: Faz o cadastro da custódia do cliente
Candidatos a Casos de Usos:
Cadastrar (Cliente e Carro)
VerificarDadosCliente (Se é cliente e se tem divida)
VerificarDisponibilidadeVeiculo
EntregarVeiculo
ReceberVeículo 
EmitirRecibo
RegistrarDivida
Candidatos a Classe:
Veículo
DadosdoCliente 
DividadoCliente
Locação
Empregado
Cenário do Caso de Uso: VerificarDadosCliente	
Nome:VerificarDadosCliente
Objetivo:Verificar se Cliente está cadastro no Sistema e divida pendente
Pré-condição:Cliente solicitar uma locação
Ator:Atendente
Fluxo Normal:
1-O atendente solicita o número do CPF
2-Digita o CPF no sistema
3-O sistema verifica se cliente está cadastrado e se tem divida pendente
4-O sistema envia mensagem cliente cadastrado e não há divida
Fluxo Alternativo 1 (Cliente não cadastrado):
4-O sistema envia mensagem cliente não cadastrado
5-Solicita o cadastro da custódia do cliente
Fluxo Alternativo 2 (Cliente com divida)
4-O sistema envia mensagem cliente cadastrado e com divida pendente
Diagrama de Seqüência
O que é Diagramas de Sequência?
É um diagrama que exibe a colaboração dinâmica entre os vários objetos de um sistema. O principal aspecto deste diagrama é que a partir dele percebe-se a sequência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos, algum evento que acontecerá em um ponto específico da execução do sistema.
Este diagrama descreve em ordem cronológica as mensagens entre os objetos. Neste momento estamos dizendo o como o Caso de Uso deve ser implementado.
Diagrama de Colaboração
O que é Diagramas de Colaboração?
É um diagramas que mostra a colaboração dinâmica entre os objetos, semelhante ao diagrama de sequência.No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos, percebe-se também os objetos com os seus relacionamentos. A interação de mensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de sequência, mas se a ênfase for o contexto do sistema, é melhor dar prioridade ao diagrama de colaboração. Podemos também escolher ambos. O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens são nomeadas, que entre outras coisas mostram a ordem em que as mensagens são enviadas. Também podem mostrar condições, interações, valores de resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que executam paralelamente com outros.
 
Ciclo de Vida
A melhor abordagem para um determinado projeto depende, em grande parte, da natureza do projeto e da natureza da organização. A escolha de um ciclo de vida errado pode atrasar a entrega do sistema ou até concluir um trabalho mau feito, por isso é preciso analisar os requisitos da organização onde se vai prestar o serviço para desenvolver o software. Partindo para a prática, a prototipagem funciona melhor para projetos de pequeno e médio porte. Ela funciona bem onde a cultura suporta equipes funcionalmente mistas. A prototipagem pode ser combinada com a abordagem em espiral e ser usada para um ou mais dos subprojetos em um desenvolvimento em espiral.
A prototipagem descreve uma abordagem que tenta satisfazer as necessidades do usuário focalizando a interface do usuário. Os estágios do projeto e de desenvolvimento, no que concerne à interface de usuários, repetem-se até que o usuário esteja satisfeito. A figura abaixo ilustra isso:
Como se pode ver no diagrama existem seis processos básicos que podemos usar no decorrer do projeto. Nota-se também que em uma parte do projeto, graças às funcionalidades do ciclo de vida em prototipagem, podemos voltar no início do processo, ou seja, no levantamento das necessidades, ou na segunda fase do processo, que é a analise de alternativas. Como os envolvidos no projeto são extremamente ocupados, conseguindo apenas 3 horas semanais para se dedicarem ao desenvolvimento do software, utilizando esse ciclo de vida conseguiremos, com o pouco de tempo de reunião, obter bons resultados positivos. Pois o contato será diretamente com os usuários, podendo nos informar rapidamente alguma dúvida ou insatisfação. Como os requisitos já são conhecidos, só nós restará obter dados baseados no conhecimento empírico de cada usuário. Com o desenvolvimento WEB poderemos mostrar e fazer testes onde estivermos, basta possuir as ferramentas necessárias. E o mais importante, com esse ciclo de vida os desenvolvedores do sistema podem interagir juntamente com o ciclo de vida em espiral, como foi dito no início do texto. No ciclo de vida em espiral poderemos reservar uma versão teste para os clientes, e receberemos o feedback através do e-mail. Mantendo contato com os clientes, sempre os informaremos quando a atualização estiver pronta, e antes de coloca-la para funcionar, basta usar um protótipo para fazer o teste e aplicar os procedimentos do ciclo de vida prototipação.
WBS – Work Breakdown Structure
Antes de observar a WBS é preciso ter uma ideia do que ela é, e para quê ela serve. Segundo definições do Guia PMBOK “WBS é o processo de subdivisão das entregas e do trabalho do projeto em componentes menores e de gerenciamento mais fácil. A WBS é uma decomposição hierárquica orientada às entregas do trabalho a ser executado pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas, sendo que cada nível descendente da WBS representa uma definição gradualmente mais detalhada da definição do trabalho do projeto. A WBS organiza e define o escopo total e representa o trabalho especificado na atual declaração do Escopo do projeto aprovado. O trabalho planejado é contido dentro dos componentes de nível mais baixo da WBS, que são chamados de pacotes de trabalho. Um pacote de trabalho pode ser agendado, ter seu custo estimado, monitorado e controlado. No contexto da WBS, o trabalho se refere a produtos de trabalho ou entregas que são resultado do esforço e não o próprio esforço”. PMOBOK®, Um guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) – Quarta Edição, PMI® – Project Management Institute, ISBN: 978-1-933890-70-8. Segue abaixo a WBS:
Essa WBS é apenas a primeira analise, com o decorrer do projeto irá surgir novas ideias que serão acrescidas na mesma. Uma WBS deve ser simples e ao mesmo tempo robusta, ou seja, que não seja grande e nem complexa demais para confundir os envolvidos no projeto, mas que seja precisa o suficiente para capturar todas as etapas que devem ser cumpridas. Após seguirmos os passos acima, teremos uma primeira versão da WBS. Esta WBS será utilizada como entrada para o planejamento de outras áreas do gerenciamento do projeto. Depois que concluirmos o projeto, teremos os relatórios referentes a cada fase do processo que seguirmos, isso no futuro nos levará a repensar se devemos mudar a WBS, acrescentar, modificar ou retirar alguns passos desnecessários. Acredito que com esse diagrama simples seremos capazes de pelo menos nos familiarizar com o projeto, afinal resultados negativos também são aceitos quando se trata de mudanças e melhoramento, pois é em cima deles que iremos aprender. 
Cronograma
Cronograma é uma maneira de colocar as etapas do projeto de maneira cronológica, ou seja, de uma forma que podemos segui-las, obedecendo às datas especificas para cumpri-las. A vantagem de um cronograma é o fato do gerente de projeto poder manter a palavra com os seus clientes, afinal a coisa mais perturbadora para um usuário é receber seu produto fora de data. Entregar o que foi prometido fora do tempo, às vezes até muito atrasado, é constrangedor para os responsáveis pelo desenvolvimento do sistema.
O cronograma a seguir será montado levando em conta as etapas do ciclo de vida e da WBS, mostrarei etapa por etapa. Ele foi montado na ferramenta CASE GanttProject. Como comenta Heldman (2002, p. 213) “É fácil ler os gráficos de Gantt, usados, na maioria das vezes, para agendar atividades. Dependendo do software utilizado para gerá-lo, esse gráfico também pode exibir sequencias e as datas de inicio e fim das atividades, alocações de recursos, dependências das atividades e o caminho crítico”.
Levantamento das Necessidades: é a fase onde serão analisados os requisitos para proceder no desenvolvimento do sistema. Coletar a partir de entrevista com os clientes toda a informação para elaborar o plano de projeto.
Análise de Alternativas: a fase onde serão analisadas as regras de negócios da empresa aplicadas ao sistema. 
Projeto: nesta fase será elaborado e mostrado os relatórios obtidos com as pesquisas técnica, capacidade, plataforma, configuração, etc.
Desenvolvimento: onde começamos a trabalhar em cima dos dados obtidos transformando-os em resultados concretos, partindo da teoria para a prática.
Implementação: partiremos para a fabricação do protótipo do nosso sistema com o objetivo de mostra ao cliente e obter uma resposta rápida.
Manutenção: essa fase é a última e a mais importante do nosso projeto, pois é aqui que concluiremos todas as etapas finalizando com teste e aprovações.
Para um gerente inexperiente elaborar um cronograma pode ser uma das coisas mais difíceis em seu começo de carreira, afinal ele não possui ainda nenhuma ideia de prazos, isso pode acarretar em prazos maus definidos, por isso é ideal sempre analisar e rever o cronograma.
Aspectos com Padrões de Segurança 
As organizações de tecnologia de informação e de desenvolvimento de software estão passando por uma mudança significativa na forma como percebem o seu próprio problema.Até pouco tempo, se fosse perguntado às empresas de médio porte a respeito da segurança de informação, a resposta incluiria, provavelmente, a frase “segurança da rede”. Esse tipo de pensamento faz parte do passado, pois em arquiteturas distribuídas, as aplicações conduzem a maioria das decisões de segurança. Por exemplo, como se deve permitir o acesso de um determinado cliente ou parceiro a dados particulares? Como resultado, as organizações estão tendo que se adaptar rapidamente e mudar o foco de uma visão de mundo centrada em redes de aplicação para segurança de software. Esta tendência ocorre com uma maior frequência nas tecnologias baseadas na Web, dando origem a uma demanda por tecnologias que buscam segurança em aplicações Web e Web Services.
  De um modo geral, segurança é uma palavra-chave no desenvolvimento de software. Notoriamente essa importância tem aumentado, pois a maioria dos ataques a sistemas exploram vulnerabilidades causadas por aplicativos mal projetados e implementados. Em decorrência dessa situação, uma coleção de padrões de segurança foi documentada para descrever soluções para problemas de segurança e, portanto, podem ser adaptados a essas dificuldades. 
Padrões de segurança são soluções reutilizáveis aos problemas de segurança que podem ser adaptadas a contextos específicos. Embora muitos padrões de segurança e técnicas para usá-los estejam sendo propostos, é complexo adaptá-los e integrá-los em cada fase do desenvolvimento de software. Ultimamente, são desenvolvidos e melhorados cada vez mais padrões de segurança, incluindo a estes, padrões para Web Services. Esses padrões são complexos e detalhados, logo não é uma tarefa simples para os desenvolvedores e usuários compreenderem seus pontos chaves. Com o objetivo de projetar, desenvolver e implantar Web Services seguros, arquitetos e desenvolvedores precisam compreender novas tecnologias e analisar as ameaças associadas à exposição de funcionalidades em redes inseguras.
  Sem uma definição clara de como os Web Services podem gerenciar e estabelecer comunicações seguras em relações de confiança com outros parceiros ou tecnologias, é difícil realizar qualquer tipo de interação. Um sistema tradicional possui os dados necessários para conhecer a priori cada usuário que o utiliza e o que cada um pode fazer. Um usuário também tem o conhecimento prévio de quais sistemas vai acessar, já possuindo os dados necessários para cada autenticação, e com autorização prévia para realizar um conjunto de operações em cada um deles.
  Para resguardar esses recursos, as organizações precisam definir políticas de segurança, que são linhas de orientação de alto nível que especificam em qual estado o sistema é considerado seguro. Essas políticas precisam ser aplicadas por meio de mecanismos de segurança. Para implementar esses mecanismos é viável aplicar alguns padrões, dentre os quais pode se destacar o uso do Authenticator e Authorization.
  Este artigo descreve como a orientação a aspectos (AOP – Aspect-Oriented Programming) pode ser utilizada para tratar requisitos de segurança como preocupações transversais, ou seja, que estão espalhadas por toda a aplicação. A orientação a aspectos proporciona um maior nível de abstração, possibilitando tratar os requisitos separadamente dos requisitos funcionais. Este trabalho propõe a modelagem de requisitos de segurança, descritos como padrões de segurança, como aspectos de software.
Segurança em Web Services
Web Services têm evoluído para integrar organizações que usam tecnologias diferentes executando em sistemas heterogêneos e frameworks. É um componente de lógica de negócios projetado para ser acessado através de uma rede utilizando protocolos padrão.
  Segurança em Web Services, de acordo com a Microsoft Corporation, engloba uma série de exigências que podem ser descritas ao longo das dimensões de segurança mais conhecidas, ou seja: integridade, pela qual a mensagem deve permanecer inalterada durante a transmissão; a confidencialidade, pela qual o conteúdo de uma mensagem não pode ser visualizado quando em trânsito, exceto pelos serviços autorizados; e disponibilidade, pela qual a mensagem é imediatamente entregue ao destinatário, garantindo assim que os usuários legítimos recebam os serviços a que têm direito. Além disso, cada Web Service deve proteger seus próprios recursos contra o acesso não autorizado. Esse, por sua vez, exige meios adequados para: identificação, pelo qual o destinatário de uma mensagem deve ser capaz de identificar o remetente; autenticação, através do qual o destinatário de uma mensagem precisa verificar a identidade do remetente; e autorização, pelo qual o destinatário de uma mensagem possui necessidade de aplicar políticas de controle de acesso para determinar se o remetente tem direito de utilizar os recursos necessários.
Conclusão
Concluímos que em um projeto é preciso definir tarefas e etapas bem detalhadas para a consecução do sistema. Quando escolhemos um ciclo de vida devemos analisar em primeiro lugar o tipo de sistema que iremos fornecer ao cliente, o ambiente de trabalho para os envolvidos no projeto. As etapas do ciclo de vida devem ser respeitadas para que não ocorram erros sutis, como atrasar ou construir alguma ferramenta de mau funcionamento. Uma WBS é primordial para separar as etapas dentro de um ciclo de vida. Apenas com um ciclo de vida não é possível saber o que se vai fazer em seguida, é nesse momento que elaboramos uma WBS com o intuito de esquematizar fases para etapas, processos mais detalhados em relação ao projeto. Entende-se que um cronograma é onde definimos as nossas datas, os prazos de entrega e de consecução dos processos envolvidos na WBS.
Não precisamos de pressa, precisamos apenas de qualidade. Com todo um esquema bem bolado podemos manter a palavra com os clientes, sem perder o foco do projeto. Em cada fase do ciclo de vida os envolvidos no desenvolvimento do sistema se dedicarão apenas a sua tarefa, apenas aquilo que lhe foi passado para fazer, pois isso evita uma sobrecarga de serviço.
Referências
Artigo Revista Java Magazine 93. Aspectos com Padrões de Segurança. Disponível em: <http://www.devmedia.com.br/aspectos-com-padroes-de-seguranca-artigo-revista-java-magazine-93/21654#ixzz30wDujpq2> Acesso: 03/05/14.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Campus, 2002.
FLORES, Emerson Ricardo. Linguagens e técnicas de programação III. São Paulo. Editora Pearson, 2012.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.0: do conceitual à implementação - 2ºed. Rio de Janeiro: Brasport, 2006.
PMOBOK®, Um guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) – Quarta Edição, PMI® – Project Management Institute, ISBN: 978-1-933890-70-8.
SANTOS, Rildo F. UML: Linguagem de Modelagem Unificada. 2009 Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376> Acesso: 03/05/14.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Pearson Addison Wesley, 2003.
Wikipédia enciclopédia livre. Banco de Dados Distribuídos. Disponível em < http://pt.wikipedia.org/wiki/Banco_de_dados_distribu%C3%ADdos> Acesso: 03/05/14