Ao longo dos anos tenho estudado e praticado a modelagem de software com UML. Participei de vários foruns de discussão, li vários artigos acadêmicos, artigos do Gartner Group, medotologias como o RUP e livros. Muitos livros.
E como acredito que a teoria na prática é diferente, pratiquei muito do que estudei sobre modelagem seja no desenvolvimento de novos sistemas ou na manutenção de sistemas existentes. Os resultados? Nem sempre animadores…
Geralmente chegava ao final da modelagem com pressão sobre o prazo de entrega do projeto, e a pergunta que sempre ouvia era: quanto do código já está pronto? Eu ainda não tinha código pronto, “apenas” os modelos. E dá-lhe pressão de prazos…
Leia mais …
Um dos grandes desafios do desenvolvimento de um bom software, certamente está em se ter um processo consistente para se capturar as necessidades do cliente, traduzí-las em requisitos e a partir daí definir os casos de uso. A partir deste ponto, como chegar ao início da codificação?
Elaborei um mapa conceitual do que entendo ser uma abordagem prática de análise e projeto de software, contemplando os seguintes artefatos:
- Documento de Visão
- Modelo de Caso de Uso
- Protótipo de Telas e Especificação de Interface Visual
- Diagrama de Classes de Análise e de Projeto
- Documento de Arquitetura do Software
- Diagramas de seqüência
- Modelo de Dados
Com essa abordagem creio que se obtém um modelo de análise e projeto consistente para o início da codificação. Veja o mapa conceitual dessa abordagem na figura abaixo. O que você acha a respeito dessa abordagem?
No desenvolvimento de software das grandes empresas as fábricas de software vem desempenhando cada vez mais um papel central. O modelo que se busca e o de delegar a programação para a fábrica e manter o foco das áreas de desenvolvimento na análise do negócio, na especificação do que será construído nos testes e implantação.
Para que um programador possa implementar um código ele necessita de uma boa solicitação, e como ela deve ser ?
Seria apenas um formulário de requisição para a fábrica onde as informações contidas nele não formam uma documentação do software, ou a requisição deve ser a própria documentação de requisito análise e projeto do sistema?
Haverá sempre a tentação de se preencher um formulário rápido e enviá-lo para a fábrica de software, pois elaborar uma documentação adequada de requisitos, análise e projeto dão um bocado de trabalho. Entretanto penso que o melhor seria elaborar uma documentação completa de requisitos e análise e projeto e essa mesma documentação passa a servir a dois propósitos: documentação do software e para envio à fábrica de software
Essa documentação deve certamente conter uma página que oriente claramente o programador sobre o que deverá ser feito para que ele não precise ler todos os documentos de requisitos análise e projeto do início ao fim. Essa página serviria como um índice rápido para que o programador pudesse localizar o tipo de informação que ele necessita na documentação existente.
Penso que esse tipo de abordagem além de atender a dois propósitos contribui ainda para a produção de um código de melhor qualidade. O você, o que pensa sobre esse assunto?
Eu em conjunto com a pró-reitoria de graduação e extensão da Universidade Camilo Castelo Branco, realizaremos o curso acima no mês de agosto de 2009.
O mercado de desenvolvimento de software tem cada vez mais especializado os papéis dos profissionais, separando as etapas de análise das necessidades de negócios, análise e projeto de sistemas, construção do software e testes. Dado a complexidade dos softwares atuais, não se admite mais que um profissional possa desempenhar todas as etapas do desenvolvimento de um software.
Esse curso dá ao participante uma visão teórica consistente e associada a prática, do processo de especificação de um software utilizando técnicas de orientação a objetos abrangendo as etapas de elicitação de requisitos, análise e projeto do software, capacitando-o a elaborar uma especificação completa de software a ser construído por um programador ou por uma Fábrica de Software.
Conteúdo:
1-Visão Geral da Análise e Projeto de Sistemas com UML
2-Metodologia de Desenvolvimento de Sistemas
3-Mecanismos Gerais da UML
4-Modelagem de casos de uso
5-Modelagem de Classes de Análise
6-Modelagem das Interações
7- Arquitetura do Software
8- Projeto de Interface Gráfica
9 – Mapeamento dos objetos para o modelo relacional
Dados sobre o curso:
INSCRIÇÕES: até 14/08/2009 –
LOCAL: Processo Seletivo – Campus II – Itaquera – São Paulo
INÍCIO DO CURSO: 15/08/2009 – TÉRMINO: 03/10/2009
HORÁRIO: 8h às12h aos sábados
CARGA HORÁRIA: 32 horas – FREQÜÊNCIA: 75%
INVESTIMENTO: R$ 200,00
Mais informações: coord.cstinformatica.sp@unicastelo.br
