Mozer Web

SUMÁRIO

2 INTRODUÇÃO 3

3 OBJETIVO..............................................................................................................................................3

4. DESENVOLVIMENTO 4

4.1. ESCOLHER UM CILCO DE VIDA ..............................................................................................4 À 5

4.1.1. DESENVOLVER UMA WBS DESTE PROJETO...................................................................5 À 10

4.1.2. DESENVOLVER UM CRONOGRAMA DO PROJETO.......................................................10 À 11

4.1.3. ASPECTO DE USABILIDADE EM IHC PARA AMBIENTE WEB.......................................11 À 12

4.1.4. NO SISTEMA WEB, DESCREVA-O ASPECTO EM PROGRAMAÇÃO WEB.....................12 À 16

5. CONCLUSÃO.....................................................................................................................................16

6. ANEXOS.............................................................................................................................................17

7.BILIOGRAFIA.......................................................................................................................................18

2 INTRODUÇÃO

Será desenvolvido trabalho referente ao conteúdo do 5.º Semestre de Analise e Desenvolvimento de Sistemas de Informação, escolhendo um modelo de ciclo de vida para o desenvolvimento do software, irei abstrair do Caso de Uso Compra de Filmes Web Mozer os objetos que irão compor as funcionalidades do aplicativo.

3. OBJETIVO

O objetivo é me capacitar acerca das matérias de Engenharia de Software, Interface Homem-Computador, Programação para Web 1, crescendo intelectualmente, um passo a mais na carreira de Analista de Sistemas onde poderei sanar minhas dúvidas, melhorar minhas habilidades de desenvolvedor e dominar toda a matéria para ingressar ao 6.º semestre onde irei me formar e começar a trabalhar no vasto mercado de trabalho que me espera.

4. DESENVOLVIMENTO

4.1 ESCOLHA DO CICLO DE VIDA

Um processo (de software) é caracterizado por meio de um conjunto de atividades bem definidas e documentadas que quando aplicadas, sistematicamente, garantem certo grau de qualidade na confecção do produto. Além do conjunto de atividades, o processo possui outros atributos como: matéria prima, mão de obra e recursos. Tais atributos são considerados os insumos do processo de produção. Salienta-se também que o processo deve possuir o conceito de retroalimentação com o objetivo de garantir o caráter evolutivo do mesmo.

Já um modelo de processo pode ser definido como uma representação ou abstração das atividades caracterizadas em um processo de software. Geralmente, o modelo norteia a instanciação e o sequenciamento das atividades de um processo de software.

O modelo cascata é o mais antigo utilizado pela engenharia de software. Sua composição é totalmente baseada nos ciclos que compõem um processo de produção da engenharia convencional. Este modelo propõe que as atividades que compõem o processo sejam sequencializadas e os artefatos gerados em uma atividade se caracterizam como a entrada da outra (click na figura no início do post).

Muitos engenheiros acreditam que este modelo caiu no desuso. Este texto contraria esta ideia, ou seja, o modelo cascata ainda é utilizado em vários projetos de software. Estes projetos, geralmente, são simples e pequenos, por exemplo – projeto de software para entrada e saída de produtos em uma pequena loja de roupas. Com certeza neste tipo de projeto você, em apenas uma interação, irá mapear cerca de 90% dos requisitos. E os outros 10?, eu classifico-os como melhoria daquilo que foi implementado.

Perceba que processos que seguem este modelo não são aplicáveis facilmente em projetos de médio ou grande porte, pois estes não seguem um fluxo sequencial de produção, os requisitos não são mapeados em sua totalidade no início do projeto e os stakeholders têm dificuldade em esperar por uma versão executável do software, fato este que ocorre somente na atividade de entrega do produto.

Enfim, se o projeto é simples e possui poucas funcionalidades, utilize o modelo cascata.

4.2 DESENVOLVER UMA WBS DESTE PROJETO.

Em Gerência de projetos, uma Estrutura Analítica de Projetos (EAP), do Inglês, Work breakdown structure (WBS) é um processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis. É estruturada em árvore exaustiva, hierárquica (de mais geral para mais específica) orientada às entregas, fases de ciclo de vida ou por subprojetos (deliverables) que precisam ser feitas para completar um projeto.

O objetivo de uma EAP é identificar elementos terminais (os produtos, serviços e resultados a serem feitos em um projeto). Assim, a EAP serve como base para a maior parte do planejamento de projeto. A ferramenta primária para descrever o escopo do projeto (trabalho) é a estrutura analítica do projeto (EAP).

A Work Breakdown Structure é um processo bastante comum. Várias resoluções de trabalho do governo dos Estados Unidos têm como requerimento uma work breakdown structure.

A EAP não é criada apenas para o gerente do projeto, mas para toda a equipe de execução do projeto, bem como para as demais partes interessadas tais como clientes e fornecedores.

COMO CONSTRUIR UMA EAP

A EAP deve ser completa, organizada e pequena o suficiente para tornar possível a medição do progresso, mas não detalhada o suficiente para se tornar, ela mesma, um obstáculo à realização do projeto. Uma boa heurística a seguir é a regra do 8-80: exige-se que um pacote de trabalho ocupe entre 8 e 80 horas de duração. É uma das partes mais importantes no plano do projeto. Ela serve como entrada para o desenvolvimento da agenda, atribuir funções e responsabilidades, gerir riscos, entre outros. Na internet e' possível acessar alguns sites para montagem gratuita de uma EAP ou WBS, tais como: http://www.wbstool.com/ Um exemplo simples de Work Breakdown Structure para pintar uma sala (orientado a entregas)

WBS WEB MOZER