Postagens

Aula 10 - Divisão e Subdivisão do Trabalho em Projetos

Uma vez definido o escopo, o próximo passo crítico é a organização do trabalho através da sua divisão e subdivisão. Projetos de sistemas para internet podem ser extremamente complexos, e tentar gerenciar o todo sem dividi-lo em partes menores é uma receita para o caos. A técnica principal utilizada para essa organização é a criação da EAP (Estrutura Analítica do Projeto), também conhecida pela sigla em inglês WBS (Work Breakdown Structure). A EAP é uma decomposição hierárquica orientada às entregas do trabalho a ser executado pela equipe. A divisão do trabalho começa no nível mais alto, que é o próprio projeto, e vai sendo subdividida em pacotes de trabalho menores e mais manejáveis. Por exemplo, em um projeto de site dinâmico, as divisões principais podem ser: Interface (Frontend), Lógica de Negócio (Backend), Banco de Dados e Documentação. Cada uma dessas áreas é então subdividida; o Banco de Dados pode ser quebrado em Modelagem, Criação de Tabelas e Scripts de Integração. Essa granu...
Postar um comentário
Leia mais

Aula 9 - Proposta de Escopo: Elaboração e Documentação

A proposta de escopo é o documento formal que cristaliza todos os entendimentos obtidos nas fases de identificação de necessidades e análise. Ela serve como um contrato técnico entre a equipe de desenvolvimento e o cliente, detalhando as entregas, as responsabilidades e as limitações do projeto. Uma elaboração cuidadosa deste documento é vital para evitar ambiguidades que podem gerar disputas legais ou financeiras no futuro. A proposta de escopo deve ser clara, objetiva e tecnicamente precisa, utilizando terminologias e simbologias padronizadas da área de sistemas. Os componentes essenciais de uma proposta de escopo incluem a descrição detalhada das funcionalidades, os requisitos não funcionais, as restrições técnicas (como sistemas operacionais e navegadores suportados) e as premissas do projeto. Além disso, as "exclusões do escopo" são fundamentais: elas explicitam o que a equipe não fará, protegendo o projeto de pedidos adicionais que não foram orçados. Documentar o que es...
Postar um comentário
Leia mais

Aula 8 - Definição do Escopo do Projeto e Qualidade

A definição do escopo é o processo de delimitar o que faz parte do projeto e, igualmente importante, o que não faz. Em projetos de sistemas para internet, o escopo atua como uma fronteira protetora contra o crescimento desordenado de funcionalidades, garantindo que a equipe mantenha o foco nos objetivos centrais. O escopo está intrinsecamente ligado à qualidade: um escopo mal definido resulta em prazos estourados e orçamentos excedidos, o que invariavelmente compromete a qualidade técnica da entrega final. Qualidade em software não significa "perfeição absoluta", mas sim o grau em que um conjunto de características inerentes cumpre os requisitos estabelecidos. Para garantir a qualidade e a produtividade, o analista deve alinhar o escopo às premissas do gerenciamento de projetos. Isso envolve definir critérios de aceitação claros para cada funcionalidade. Se o escopo diz que o sistema terá um módulo de pagamento, a qualidade definirá que esse módulo deve ser seguro, rápido e l...
Postar um comentário
Leia mais

Aula 7 - Identificação de Necessidades e Requisitos dos Usuários

A identificação de necessidades é o alicerce fundamental sobre o qual todo o projeto de software é construído. Em um cenário de desenvolvimento para internet, onde a concorrência está a apenas um clique de distância, compreender exatamente o que o usuário precisa — e não apenas o que ele diz que quer — torna-se um diferencial estratégico. Este processo, frequentemente chamado de elicitação de requisitos, exige que o analista de sistemas atue como um investigador e tradutor, interpretando dores de negócio em funcionalidades técnicas concretas. O levantamento de requisitos não é uma atividade passiva; ele envolve o uso de técnicas modernas como entrevistas estruturadas, workshops de design thinking, observação direta (etnografia) e a análise de sistemas legados. O objetivo é capturar os requisitos funcionais, que descrevem as tarefas que o sistema deve executar, e os requisitos não funcionais, que definem propriedades como desempenho, segurança, usabilidade e escalabilidade. Sem essa dis...
Postar um comentário
Leia mais

Aula 6.1 O Modelo em Cascata

Imagem
Os modelos sequenciais se preocupam em organizar o processo em atividades sequenciadas linearmente. O principal modelo com essa característica é o modelo em cascata, a partir do qual diversos outros modelos foram propostos, inclusive modelos incrementais e evolutivos. Comumente chamado de modelo de ciclo de vida clássico, o modelo em cascata organiza as atividades do processo de software de forma sequencial, como demonstra a figura 1.1, em que cada fase envolve a elaboração de um ou de mais artefatos que devem ser aprovados antes de a fase seguinte ser iniciada. Assim, uma fase só deve ser começada após a conclusão daquela que a antecede. Uma vez que, na prática, essas fases se sobrepõem de alguma forma, geralmente, permite-se um retorno à fase anterior para a correção de erros. A entrega do sistema completo ocorre em um único momento, ao fim das fases de entrega e de implantação. Pode-se dizer que o modelo em cascata é o modelo de ciclo de vida mais antigo, no entanto, críticas questi...
Postar um comentário
Leia mais

Aula 6 - O Ciclo de Vida e Processos de Software

  O desenvolvimento de um sistema não ocorre de forma caótica; ele segue uma estrutura lógica conhecida como Ciclo de Vida de Software . Este ciclo define as etapas pelas quais um sistema passa, desde a sua concepção inicial até a sua aposentadoria ou desativação. Compreender esses estágios é fundamental para que o analista possa aplicar os processos de software de maneira a garantir a previsibilidade e a qualidade da entrega final. Embora existam vários modelos, a maioria compartilha fases essenciais: Levantamento de Requisitos, Análise, Projeto (Design), Codificação, Testes e Manutenção. O modelo mais tradicional é o Cascata (Waterfall) , onde cada fase deve ser concluída antes que a próxima comece. Embora seja fácil de entender e gerenciar, ele apresenta riscos elevados em projetos de software, pois o cliente só vê o resultado final após meses de trabalho, quando ajustes podem ser caros ou impossíveis. Para mitigar isso, surgiram modelos iterativos e incrementais, como o Modelo ...
Postar um comentário
Leia mais

Aula 5 - Premissas do Gerenciamento de Projetos de Software

Gerenciar software é fundamentalmente diferente de gerenciar a construção de um prédio ou de um automóvel. O software é um produto intangível e invisível em sua essência, o que cria premissas únicas para o seu gerenciamento. Uma das premissas básicas é que a complexidade do software não cresce de forma linear, mas sim exponencial, à medida que novas funcionalidades são integradas ao sistema. Isso exige que o analista de sistemas utilize técnicas de modularização e divisão do trabalho para manter o controle sobre o projeto. Outra premissa crítica é a volatilidade dos requisitos. Em projetos de software para internet, é quase certo que o que o cliente deseja hoje mudará à medida que ele visualizar os primeiros protótipos. Portanto, o gerenciamento deve assumir a mudança como uma constante, e não como um erro de planejamento. Isso leva à necessidade de processos de software que permitam revisões contínuas e validações parciais, evitando que a equipe trabalhe por meses em algo que já se to...
Postar um comentário
Leia mais