After development cycle comes QA, this is common in commercial software development. The QA cycle has specific goals: check the result according to specifications, check for abnormal behavior and try to "abuse" the system in ways the end user might do for stability assurance. My colleague Shai has a blogexplaining the different goals of QA. This is the theory, but as we all know, theory in practice is somewhat different.
In practice QA is a mix of conflicting tasks:
Recreate the requirements
Create the end user abuse
Understand the actual development
Integration of the development
Generate simulated and real data to test upon
On top on these, there should be also prioritization of the tasks and communication of the findings. Mix it all together and the QA becomes a bottle neck, delaying the release of the software even more.
The management perspective on QA, due to the reasons above, is that QA hinders the development and is a nuisance more than a benefit, in turn causing the management to decrease the investment in QA and thus increasing the numbers of problems found by the customer, creating a negative feedback loop.
How do you get out of this loop? How do you create a QA that is effective, streamlined and can actually provide a benefit to the company?
There are no easy answers, but there are general guidelines:
Have a process: for the requirements, for the development documentation and for the QA.
Allow for enough time for thing to settle: there is a minimal amount of time to coordinate the software components before they play well together - i.e. integration time.
Spend time educating the QA management on the process and the priorities while carefully pruning misguided tasks.
Since we are talking of software systems, remember that there are some common misconceptions and pitfalls; programmers are optimistic and the timeframes will be longer than expected, same for QA planning and execution.
The QA group can be a real asset, built and maintained correctly as described by Joel on software. Even more important, it can help the company reach the proclaimed goals by helping the company define the goals and communicating them at various levels.
Being disconnected from the internet is a nightmare; we are so dependant on the information received from the internet that even a small disconnection makes life difficult. I learnt it the hard way this week by having a connectivity problem, and making things worse, I lost the configuration of the ADSL modem. This is exactly the reason backups and information management is crucial.
I have a SpeedTouch Home ADSL modem made by Thomson / Alcatel. The firmware was upgraded to 510, with custom configuration as bridge for PPPoE connectivity. This seems quite trivial, but the exact configuration detailing the VC/VP and other details was lost. The modem isn't produced anymore, and the website hosting the manuals is long gone; I had to google for the CLI commands and try to recreate the correct sequence for setting up the bridge. After finally creating it, I downloaded the configuration to a txt file and saved it on the SVN as backup. This seems like the end of it, but it got me thinking of the next phase, on the moment I might need it.
Information management is always a problem because we generate lot of information for work or personal, normally not keeping track of it. Like normally done for problem solving, the problem should be stated:
"How can I keep information on my computer so I would be able to find it later?"
"What is the type of information and how it's organized?"
"How do I find the Information?"
The answer to the first two items is easy: most of the information come in text files, whether word documents, presentations or other text files. Sometimes we might like to add also the images files, but this is out of scope for now.
What are the options? (The list isn't comprehensive list, but an overview of options)
Google desktop: I use the application at work. The application indexes all of the files on your computer, including the emails and can provide a comprehensive search using keywords.
Personal wiki: The wiki serves as a semi organized information manager. The benefit is organizing the information with a scratchpad while still keeping some search functionality.
Personal Information Manger (PIM): similar to personal wiki, but able to contain more information types like emails and contacts.
Each of the possible solutions can be used, more often a combination of several. At work I use outlook as PIM for email, contacts and calendar, while google desktop helps me find the information using keyword search. This might not be the best information management solution but it helps storing information and retrieving it when needed.
The act of system design requires making many decisions: small ones like selecting details, directing people and large ones like selecting the decomposition or describing the general design guidelines. Since the designer can also be part of the problem, there is an inherent risk in the design process. The decision making process can be skewed or biased and provide unwanted results.
This skewing can be a road to hell in little increments: selecting technologies due to past experience although the situation is different, making haste decisions, lack of documentation and any other of the many decisions taken in the project lifecycle. If the decisions have a tendency of repeating the previous project or to neglect the current project differences, the design might have lack of attention to the important parts and in that providing less than best solution under the constraints.
The process of software architecture can help identify the biases in the design and help the decision taking to be focused on the current project requirements. The reason for being focused lays in two major steps taken in the design:
Quality attributes analysis and specification: since quality attributes are very formally specified, they can serve as very exact guidelines.
Detailed tactics analysis: the full tactics taxonomy can be used for evaluation of the effectiveness of each possibility against the requirements.
Following both steps can provide an effective checklist, of the requirements and of the possible solutions.
In the long run using a check list for verifying that the requirements have been taken can help making better products by decreasing the chance of architectural omissions. My experience has shown that any chance of human error can and will happen, so using methodologies for aiding the decision taking technique is a must. The net result is that although the designer has limitations, the process can cope with some of the limitations and the decision not being a road to hell.
Software architecture occurs, whether you plan it or not, whether you agree or not. This fact was the major reason I decided to share my understandings from the software architecture, and try to use a directed effort in the design of our system, hoping to improve the quality and the understanding of our limitations. Most of the information is form the book "Software Architecture in Practice" from Addison Wesley.
Rick Kazman writes in the book that quality attributes guide us in the design process because the same functional requirements can be fulfilled by different architectures, but different architectures provide different quality attributes. A good example is processing data in a batch process or a pipe process. The first one provide better throughput, but is more difficult to change. The second had lower throughput but is more flexible.
Using an iterative process, taking quality attributes in consideration, there is a decomposition stage, according to the main architectural pattern. The decomposition takes into account some of the functional requirements but in not too detailed. The reason for limiting the details is the iterative process, meaning that each step reduces the generality and provides enough details for the next iteration.
In addition to the functional requirements, some architectural tactics should be taken. What are those tactics? Those are the fundamental design decisions that help us achieve the required quality attributes.
I still have to organize the presentation, so I'm a bit stuck here. I will continue this week and see how the information can be explained
