TDD What ? New or old ? Good or no ?

Currently or since I know myself as a professional, software failures are largely responsible for costs and time in the software development process.

While it is not possible to remove all existing errors in a given application, it is possible to considerably reduce the number of errors using a more elaborate testing infrastructure, which allows for identifying and removing defects earlier and more effectively.

These defects can result from various causes such as errors of knowledge, communication, analysis, transcription, coding, etc. There are basically three ways to handle software flaws:

1. Fault-avoidance: With appropriate specification, design, implementation and maintenance activities always aiming to avoid failures in the first place. It includes the use of advanced software construction methods, formal methods, and reuse of trusted software blocks.

2. Fault-elimination: Analytical compensation for errors committed during specification, design and implementation. Includes verification, validation and testing.

3. Fault-tolerance: real-time compensation of residual problems such as changes out of specification in the operating environment, user errors, etc.

Due to the fact that fault-avoidance is economically impractical for most companies, the technique of fault elimination is generally adopted by software manufacturers

In the US, do these errors move the software market by approximately 50 billion dollars, and in Brazil and South America? We can see that there is a culture of everything by the result, and after delivery by delivery, in many projects and forgotten the quality be it in the software architecture or in the choice of the project implementation strategy, the DEADLINE is focused by the DEADLINE.

Another point is the bureaucratization of technical activities, process must exist but these should also be support to the objectives and not against the objectives that includes being agile, safe, reusable, practical and that make a culture in the company be it with 10 professionals or with 100 In a company.

The culture of testing is old, as it says in King Chelomoh's Cohelet book, nothing new is just not revealed.

The practice involves the implementation of a system starting with test cases of an object, this is old, I at least have known these techniques since 1999, I will cite only one that defends this idea [Gelperin and Hetzel 1987]. Minimize the errors by focusing on the tests, and today as we are in the era of "JS frameworks", there is a semantics of confusing the implementation framework with work process framework with tools of griffe, which does not apply if they are not tested in the process by All, for all, not only by the 18-year-old project architect, this 18-year-old nowadays grant the role of software architect, senior software development positions to good early professionals, but with little experience, which For me 1996 was almost impossible to have a Jr. level in my classificatory parts of technical activities of the profession, I thought more imperative implementation than clear techniques, there have been many improvements, but today TDD - Test driven development can be put at high risk If you do not have experience in IT projects with software development with serious errors and also great achievements.

In many different techniques, used in the market and tested in the academic world, and professional can, I say by myself also, that the use of this technique is possible to reduce the complexity of software, increasing the maintainability of it. Failures are easily identified even in the development stage thanks to continuous feedback given to the programmer. The test units created allow you to more easily evaluate new defects that may have been inserted in the software facilitating the development of successive releases.

But a detail the professionals who do this are also with attributes of programmers, systems analysts know the world of implementation, this is my opinion for the success of TDD, adjust to lead to good results.

One good choice use systems development with MDA - Model Driven Architecture

One good choice use systems development with MDA - Model Driven Architecture

The system development lifecycle process is a problem-solving process where requirements maybe considered problems occurring within a domain, systems that address the requirements may be considered solutions residing within an environment, and problem solving involves understanding a problem, solving the problem, and implementing the solution. 

One choice to solving problem of process of development is using MDA as good choice and with development tools integrate. Can implement with languages as Java, Python, C++.

Every system development lifecycle process involves the following types of lifecycle activities:

• Requirements gathering activities to capture requirements that define what a system should do. This results in a requirements model that describes the problem and what a solution entails, and is said to occur from a conceptualization perspective since it focuses on the problem.
• Analysis activities to understand the requirements. This results in an analysis model that describes how an abstract or implementation-independent solution satisfies what is specified by the requirements model, and is said to occur from a specification perspective since it focuses on the problem and solution.
• Design activities to determine how a system will satisfy its requirements. This results in a design model that describes how a real or implementation-specific solution satisfies what is specified by the analysis model, and is said to occur from a specification perspective since it focuses on the problem and solution.
• Implementation activities to build a system. This results in an implementation model that describes the actual solution or physical system that satisfies what is specified by the design model, and is said to occur from an implementation or realization perspective since focuses on the solution.
• Testing activities to verify that a system satisfies its requirements.
• Deployment activities to make the system available to its users.

Furthermore, there are many types of approaches or lifecycle models, bellow :
 1. Iterative,
 2. Waterfall,
 3. And so forth

Applying these activities, however every approach must confront the forces of change and complexity.

Figure 1 shows a conceptual view of the system development lifecycle process.

The domain and environment are shown as circles. The problem and solution are shown as solid-outline rectangles within the circles. The problem-solving process is shown as a solid-line path from the problem to the solution, and each perspective is shown as a dashed-line path from the solid-line path to the activities related to that perspective. Activities are shown as a shape with a straight top and bottom and convex arcs on the two sides, and models are shown as solid-outline rectangles.

When an activity uses a model as input, a dashed arrow is shown from the model to the activity. When an activity produces or updates a model as output, a dashed arrow is shown from the activity to the model. Because the requirements model represents the problem and the implementation model represents the solution, a dashed arrow is shown from each model to the item it represents...

Como reforçar as atividades essenciais de um projeto ou de processo

Projetos de otimização de processos consistem em realizar o trabalho de ajustar um processo buscando sua melhoria. De acordo com Reint Jan Holterman, autor do white paper “Five Common Pitfalls in Process Optimization, And how to avoid them“, e de acordo com o livro do matemático Alkhaziri em meados do século 19 onde os grupos para empreender e ajustar produção faziam um esboço de um plano usando cálculos e figuras, que podemos dizer da fronteira do Norte da África ao Oriente Médio já utilizavam avançados métodos para  que os esforços de otimização tinham o objetivo de “ reforçar as atividades essenciais da empresa, produzindo melhores produtos e serviços, em um período mais curto de tempo, a um esforço ou custo mais baixo ”.  As atividades essenciais devem controlar a produção em a cada revisão estar melhor para objetivar menor esforço e alcance dos objetivos.

Qualquer planejamento a ser executado para a otimização de processos requer, então, que se possa produzir uma visão de futuro melhor para a execução de um processo olhando para a forma como ele acontece atualmente e seu histórico (lições aprendidas). Envolve atividades de modelagem, análise e redesenho do processo, e apesar de este ciclo já se constituir em uma prática comum em organizações que buscam a melhoria de processos através das práticas de BPM, estima-se que 60 a 70% de todos os processos de otimização não produzam resultados satisfatórios (leia mais aqui: http://esopsfables.wordpress.com/2012/02/29/why-process-improvement-projects-fail/).

Em seu white paper, Holterman e Alkhaziri exploram as cinco falhas mais comuns, responsáveis pelos problemas neste tipo de projeto:

1. Falta de clareza sobre onde começa e onde termina o trabalho

Muitos projetos são iniciados com uma declaração “vamos otimizar o processo tal”, mas não está claro para a equipe por onde começar e até onde se vai.

A falta de clareza sobre o início e fim do projeto leva a uma sequência de armadilhas que resultam em um processo desestruturado e interminável.

Em um projeto de otimização de processos é fundamental compreender a situação atual, o status quo do processo. Quem está envolvido, quais são as entradas e saídas, quais são os limites do escopo deste processo, qual é o tempo que o processo leva atualmente para ser executado, que exceções comumente levam a resultados diferentes e com que frequência acontecem, são questões iniciais que precisam ser feitas antes mesmo de se iniciar alguma ação de otimização.

Conhecer bem a situação atual do processo é tão importante quanto ter claro onde se quer chegar. É preciso que todos os participantes tenham uma visão clara de que melhoria deseja-se atingir com o projeto, se é um ganho de produtividade, de redução de tempo, de redução de custos, e que parâmetros definirão o atingimento do resultado esperado.

2. Usar indicadores (KPIs) inadequados

Os indicadores de performance (KPIs) são as referências que apontam a direção para a linha de chegada. Indicadores mal definidos levarão a equipe a sair do curso, já que apontam para a direção errada.

Sintomas comuns de um KPIs mal definido:

• não está relacionado ou é impactado muito levianamente pelo processo de negócio;
• pode gerar interpretações diferentes;
• não é impactado apenas pelo processo, mas também por  fatores externos;
• não está relacionado de alguma forma aos objetivos estratégicos da organização, de forma que mesmo que o processo obtenha alguma otimização, não há garantia que produzirá algum resultado melhorado para a empresa.

3. Falta de apoio do dono do processo e da alta gestão

O Patrono ou Dono do Processo (Processo Owner) é o responsável pelo desempenho do processo de negócio, e espera-se que seja o maior interessado no sucesso de um projeto de otimização, já que afetará diretamente os resultados do produto ou serviço gerado pelas atividades do processo de negócio. Consequentemente, sem um Dono do Processo que se importe em acompanhar o trabalho de otimização do seu processo (seja por falta de interesse ou de tempo para apoiar o trabalho), não se pode esperar grandes resultados do projeto.

Também o apoio da alta gestão da empresa ao projeto de otimização é essencial para o sucesso da iniciativa, de forma a garantir o envolvimento e a disponibilidade dos recursos necessários às ações de melhoria.

4. Não adotar as mudanças no processo

É da natureza humana apresentar resistência a mudanças – mudar envolve sair da zona de conforto, aquela em que conhecemos e controlamos como as coisas funcionam.

Por este motivo, comunicar bem e garantir que os envolvidos tenham tempo suficiente para compreender e aceitar as mudanças propostas é fundamental para o sucesso da implantação de otimizações no processo. As pessoas precisam entender por quê as mudanças estão sendo feitas para assimilar os benefícios a serem obtidos e efetivamente adotá-las.

5. Displicência na execução

Holterman e Alkhaziri aponta que em muitas organizações, os projetos de otimização acabam se perdendo em um perpétuo estudo e desgastante levantamento de informações, colecionando e analisando todo tipo de dado que se pode coletar acerca do processo na tentativa de representá-lo da forma mais apurada, às vezes envolvendo até mesmo coleta de informações de outros processos que nem estão diretamente relacionados ao escopo de otimização prevista no projeto. Mas dispender toda energia em gerar estatísticas complexas e painéis de monitoramento não trarão resultados práticos de otimização.

Controlar a execução, garantindo que as otimizações definidas sejam efetivamente executadas como planejadas, são um dos grandes desafios de um projeto de otimização e podem encontrar suporte na implementação do processo em um BPMS (Business Process Management System).
Uma notação deve ser como um "idioma" na nossa comunicação.

Os jornalistas e o BPMN, o que ?

O profissional de Implementação BPMN e a realidade... e os jornalistas ?

Frequentemente nos deparamos com questões a respeito das habilidades e conhecimentos do Analista de Processos, também chamado de Analista de Negócios ou ainda de Analista de O&M (Organização e Métodos), o que nos leva a crer que não é clara a descrição do perfil para este papel e nem seja consenso no mercado a definição de suas atribuições e responsabilidades. A partir de uma visão ampla do que é a Gestão de Processos de Negócio (BPM – Business Process Management), percebemos a necessidade de adequação nas responsabilidades deste profissional, cada vez mais necessário nas organizações.

O Analista de Processos ainda é visto em algumas empresas como um cargo meramente operacional, dedicado a executar demandas de mapeamento e/ou desenho dos processos atuais, sendo conhecido por estar rodeado de fluxos e matrizes de impacto. Porém, com a crescente competitividade e busca por soluções visando uma maior constância das organizações, hoje o mercado demanda um profissional de processos com ampla visão estratégica, foco no negócio da empresa e que seja o elo de ligação entre as áreas de negócio e as áreas de apoio, como TI e RH, não apenas transmitindo necessidades das áreas interessadas, mas como um facilitador da comunicação entre as partes.

Este profissional deve expandir a abrangência do seu papel atual, tendo como objetivo sempre a busca pela melhoria do resultado dos processos e, conseqüentemente, da empresa, procurando assim integrar os objetivos organizacionais com os objetivos dos processos da cadeia de valor da empresa. Para isto, é necessário que ele identifique e implante melhorias tanto nas atividades manuais (processos e pessoas) como também através de automações, tarefas estas que só se tornam possíveis mediante a integração e envolvimento no trabalho das áreas envolvidas. Assim, este novo papel não apenas sugere que o profissional execute suas atividades operacionais de mapeamento, mas que seja um multiplicador e motivador em toda a empresa da importância da Gestão de Processos de Negócio como uma iniciativa contínua de melhoria e parte integrante do modelo de gestão da empresa.

O contexto de atividades deste profissional não podemos esquecer que é derivativo da UML - Unified Model Language que é matemática, exata para apoio em definição de requisitos para construir um software são parte de passos para desde requisitos até o que antecede a implementação, testes e homologação de um software bem construído, a UML deve é consolidou seu lugar o que derivou o entendimento não só por arquitetos de software, engenheiros de software, programadores, administradores de sistema de banco de dados mas por chamados " stakeholders "ou agentes de negócio do projetos onde eles definem os requisitos em nesta classe há camadas e uma delas é o analista de negócio onde empresas tentam antes de escolherem um software pré-pronto a ser customizados dentro de uma framework definida a adequar aos requisitos funcionais com pseudos linguagens que estes especialista em fluxos de negócios e não em fluxo de linguagem de programação, foi assim resumidamente nesta minha tentativa de explicar criada notações derivadas da UML como o BPMN ou Business Process Management Notation com uma carga mais de subjetividade do que a objetividade de diagramas dinâmicos e estáticos da UML.

BPMN to UML to PROGRAM Ok ?  Entenderam ??!!! 

Neste tempo estamos ainda em um momento de transição, é natural que tanto alguns profissionais como algumas corporações ainda estejam se adequando a este modelo proposto.

Há muitas dúvidas neste mercado onde empresas não querem entender que as vezes escolher um software pronto ou desenvolver um próprio há passos que devem seguir e são pulados como um tema  ineterssante como este é  quem controla a internet são os jornalistas que se renderam a internet ou dos "INFORMATAS" que criaram a internet ??  Quem ?  

SAAS é realidade ou não ?

O mundo é quase SAAS...

Tais aplicações “incluem muitas vezes o acesso para muitas equipes de funcionários dispersas, sendo um bom candidato para a implantação de plataformas de SaaS “, escreveu Scavo. Aos serviços de plataformas de RH seguem-se os de CRM e de aplicações de colaboração, com 31% dos pesquisados indicando as duas áreas como tendo prioridade no investimento.

Cerca de 25% dos entrevistados indicaram interesse de uso de ERP no modelo SaaS. “Apesar de os ERP e os sistemas de contabilidade serem a categoria mais amplamente implementada de aplicações de negócios em geral, são menos populares para a implantação de SaaS “provavelmente devido ao fato de estarem “mais enraizados e terem uma abrangência mais vasta”.

Apenas 11% dos participantes do estudo expressaram interesse em serviços de SaaS para suportar relatórios de despesas.

A atomização dos interesses dos compradores de SaaS também se manifesta pelo fato de 24% dos entrevistados terem assinalado a categoria “Outros”.

No geral, a adoção de SaaS está crescendo devido aos seus benefícios de acesso, segurança, menos volatilidade em manter o hardware necessário. Os entrevistados assinalaram a velocidade de implantação como o benefício principal, seguido pela redução das infraestruturas de TI, a maior facilidade de expansão e de atualização, de acordo com o estudo.

No entanto, classificaram a disponibilidade e as capacidades de Disaster Recovery como sendo menos importantes quando se trata de SaaS, acrescenta o estudo. “Os fornecedores de software tradicional argumentam que , no longo prazo, a sua oferta muitas vezes custa menos do que as aplicações em SaaS “, o que hoje uma empresa quer usar e se manter com sistema desktop, se ela pensa assim em seu plano imagine na execução.

“É possível que os decisores de TI acreditem nesse argumento” Será ?  

Os preços de subscrição, marca registada do SaaS, não estão bem classificados na lista dos maiores benefícios swgundo os participantes do estudo. Pode haver uma razão para isso, também: os fornecedores de serviços de cloud “argumentam que a subscrição transforma os gastos com software em uma despesa operacional, e para algumas empresas isso proporciona um quadro fiscal mais favorável “, afirma ele. “No entanto, os fornecedores de software instalado localmente também podem facilmente fornecer o mesmo benefício, financiando a compra de licenças de software como um aluguel”.

No topo das preocupações dos entrevistados com o modelo SaaS, estão os riscos de privacidade dos dados – a maior preocupação –, seguido por outras questões de segurança, a perda de controle sobre a informação, os desafios de integração e de desempenho.

Day by day as Software Architecture, not easy..and mistakes

Software Architecture Mistakes

1. Scoping Woes. "This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality...It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation?"
2. Not Casting Your Net Widely. "A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention."
3. Just Focusing on Functions. "…unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful."
4. Box and Line Descriptions. "There are two reasons why the [single, all inclusive] huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean."
5. Forgetting That It Needs to be Built. "Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working."
6. Lack of Platform Precision."…its no longer sufficient to simply say that you “need Unix and Oracle” when specifying your platform. You need to be really precise about the specific versions and configurations of each part in order to ensure that you get what you need. This will allow you to avoid the situation where you can’t deploy your system because someone has helpfully upgraded a library for one part of the platform without realising that it means that something else will no longer work."
7. Making Performance and Scalability Assumptions. "Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming. This will all help to increase confidence that there aren’t any performance and scalability demons lurking in your design."
8. DIY Security. "A mistake made in many systems over the years has been to try to add security into the system using “home brew” security technology. Be it custom encryption algorithms, a developer’s own auditing system or an entire DIY access control system, locally developed security solutions are rarely a good idea. While most of us think we could probably whip up a clever piece of security technology in no time, we’re usually wrong."
9. No Disaster Recovery. "The key to getting resources to implement a DR mechanism for your system is to be specific and quantify the cost of system unavailability in a number of realistic scenarios. If you can also estimate the probability of the scenarios occurring then you can use these two figures to convince people that DR is important and to justify a certain level of budget to implement it."
10. No Backout Plan. "Make sure that whatever happens during the deployment of your system or upgrade that you have a documented, reviewed and agreed backout plan to allow you to restore the environment to its state before you started deployment."

About SQL Command Insert " large number rows "

Many friends Software Architect, DBA, QA Analyst questions about SQL Insert " large" ?

( Oracle Database )

Question:  What are the steps for tuning an insert SQL?  

It's running far too long and I need to understand how to optimize the insert for performance. 

Answer:  Many factors that effect Oracle insert SQL performance and many things that you can do to tune an insert statement.  When loading large-volumes of data, you have several choices of tools, each with their own costs and performance benefits. 

Some insert tuning techniques that can work in a multitude of workloads.  Remember, you can have choices for doing table inserts including the Data Pump and SQL*Loader utilities, as well as PL/SQL bulk load tools such as theforall operator There are many types or Oracle inserts, each with distinct performance characteristics:

=======================================================================

The fastest Oracle table insert rate I've ever seen was 400,000 rows per second, about 24 million rows per minute, using super-fast RAM disk (SSD), but Greg Rahn of Oracle notes SQL insert rates of upwards of 6 million rows per second using the Exadata firmware:

"One of the faster bulk (parallel nologging direct path from external table using direct path compression) load rates I've seen is just over 7.7 billion rows in under 20 minutes which equates to around 385,000,000 per minute or about 6,416,666 per second.

All the CPUs are running at around 99% user CPU during that load. That was loading to spinning rust (Exadata Storage). It would be even faster had compression not been used. That was on a HP Oracle DB Machine (64 Intel Harpertown CPU cores). "

While my complete notes are found in my book "Oracle Tuning: The Definitive Reference", I have my main notes on tuning inserts here, but here are some general guidelines for tuning inserts statements. 

a - Disable/drop indexes and constraints - It's far faster to rebuild indexes after the data load, all at-once. Also indexes will rebuild cleaner, and with less I/O if they reside in a tablespace with a large block size.

b - Manage segment header contention for parallel inserts - Make sure to define multiple freelist (or freelist groups) to remove contention for the table header. Multiple freelists add additional segment header blocks, removing the bottleneck.  You can also use Automatic Segment Space Management (bitmap freelists) to support parallel DML, but ASSM has some limitations.

c - Parallelize the load - You can invoke parallel DML (i.e. using the PARALLEL and APPEND hint) to have multiple inserts into the same table. For this INSERT optimization, make sure to define multiple freelists and use the SQL "APPEND" option.  Mark Bobak notes that if you submit parallel jobs to insert against the table at the same time, using the APPEND hint may cause serialization, removing the benefit of parallel jobstreams.
 

d - APPEND into tables - By using the APPEND hint, you ensure that Oracle always grabs "fresh" data blocks by raising the high-water-mark for the table. If you are doing parallel insert DML, the Append mode is the default and you don't need to specify an APPEND hint.  Mark Bobak notes "Also, if you're going w/ APPEND, consider putting the table into NOLOGGING mode, which will allow Oracle to avoid almost all redo logging."
insert /*+ append */ into customer values ('hello',';there');
 

e - Use a large blocksize - By defining large (i.e. 32k) blocksizes for the target table, you reduce I/O because more rows fit onto a block before a "block full" condition (as set by PCTFREE) unlinks the block from the freelist.

• See benchmark test of blocksize and inserts here
   
• See general benefits of multiple blocksizes here

f - Use NOLOGGING

f - RAM disk - You can use high-speed solid-state disk (RAM-SAN) to make Oracle inserts run up to 300x faster than platter disk.

Insert performance (blocksize)

When begin test, action,  my small single-CPU, single-user benchmark showing the performance of loads into a larger blocksize:

alter system set db_2k_cache_size=64m scope=spfile;
alter system set db_16k_cache_size=64m scope=spfile;
startup force
create tablespace twok blocksize 2k; <-- 100m="" asm="" br="" defaults="" to="" using="">create tablespace sixteenk blocksize 16k;
create table load2k tablespace twok as select * from dba_objects; < creates 8k rows
drop table load2k; <- br="" buffers="" create="" first="" preload="" to="" was="">

set timing on;
create table load2k tablespace twok as select * from dba_objects;
create table load16k tablespace sixteenk as select * from dba_objects;

For a larger sample, I re-issued the create processes with:

select * from dba_source; -- (80k rows)

Even with this super-tiny sample on Linux using Oracle10g (with ASM) the results were impressive, with a significant performance improvement using large blocksizes.

             2k        16k
      blksze         blksze
8k table size   4.33 secs     4.16 secs  
80k table size   8.74 secs     8.31 secs 

Optimizing Oracle INSERT performance

The fastest Oracle table insert rate I've ever seen was 400,000 rows per second, about 24 millions rows per minute, using super-fast RAM disk (SSD).

Speed of inserts is primarily a function of device speed, but NOLOGGING, maximum parallel DML (which, in turn, a function of the number of CPU's and the layout of the disks) also factor into the equation. When using standard SQL statements to load Oracle data tables, there are several tuning approaches: 

Using SSD for insert tablespaces

For databases that require high-speed loads, some shops define the insert table partition on solid-state disk (later moving it to platter disk).  Mike Ault notes in his book "Oracle Solid-State Disk Tuning", a respectable 30% improvement in load speed:

“In the SSD verses ATA benchmark the gains for insert and update processing as shown in the database loading and index build scenarios was a respectable 30%.I
This 30% was due to the CPU overhead involved in the insert and update activities.
If the Oracle level processing for insert and update activities could be optimized for SSD, significant performance gains might be realized during these activities."