Verification and Validation are the two forms of testing software.
Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on review of non-executable methods.
Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated.
Verification answers the question, “Did we build the right system?” while validation addresses, “Did we build the system right?”
Verification requires several types of reviews, including requirements reviews, design reviews, code walkthroughs, code inspections, and test reviews. The system user should be involved in these reviews to find defects before they are built into the system. In the case of purchased systems, user input is needed to assure that the supplier makes the appropriate tests to eliminate defects.
Validation is accomplished simply by executing a real-life function. This includes unit testing, integration testing, system testing and user acceptance testing. In this rigorous testing is conducted to validate if the system meets the functional requirement.
Sunday, October 7, 2007
Friday, October 5, 2007
Save-Restore Commands:
We have a partition for production and one for development. We struggle with copying data and source code between the two machines. FTP copies source members without a problem, but it drops the modification dates on the source records. To copy data files, we can use save files in binary mode, which is a hassle. Also, setting up a scheduled job to refresh certain files on the test system from the production system at night, and while FTP would work; it would be difficult for the job to determine if the transmission succeeded.
A better way to this is to use the SAVRSTxxx commands, especially Save Restore Object (SAVRSTOBJ). Two other commands that we might need occasionally are Save Restore Library (SAVRSTLIB) and Save Restore Objects (SAVRST), for the IFS. There is also Save Restore Configuration (SAVRSTCFG), Save Restore Changed Objects (SAVRSTCHG), and Save Restore Doc/Lib Object (SAVRSTDLO) commands.
The SAVRSTxxx commands go through a process similar to the binary FTP of save files, but without the hassle. Here are some examples.
This command copies data file SOMEFILE from the production system to the DEV system.
SAVRSTOBJ OBJ(SOMEFILE) LIB(MYLIB) RMTLOCNAME(DEV)
OBJTYPE(*FILE)
This command copies an entire source physical file to the test system.
SAVRSTOBJ OBJ(QRPGLESRC) LIB(MYLIB) RMTLOCNAME(DEV)
Here's a command to copy one RPG source member, MYSRCMBR, from production to Development. Notice MBROPT(*NEW) was used here, because the source member did not already exist in QRPGLESRC on the Development system.
SAVRSTOBJ OBJ(QRPGLESRC) LIB(MYLIB) RMTLOCNAME(DEV)
OBJTYPE(*FILE) FILEMBR((QRPGLESRC (MYSRCMBR))) MBROPT(*NEW)
Another nice thing about the SAVRSTxxx commands is that they do not require enrollment in the system distribution directory, as SNDNETF (Send Network File) does.
A better way to this is to use the SAVRSTxxx commands, especially Save Restore Object (SAVRSTOBJ). Two other commands that we might need occasionally are Save Restore Library (SAVRSTLIB) and Save Restore Objects (SAVRST), for the IFS. There is also Save Restore Configuration (SAVRSTCFG), Save Restore Changed Objects (SAVRSTCHG), and Save Restore Doc/Lib Object (SAVRSTDLO) commands.
The SAVRSTxxx commands go through a process similar to the binary FTP of save files, but without the hassle. Here are some examples.
This command copies data file SOMEFILE from the production system to the DEV system.
SAVRSTOBJ OBJ(SOMEFILE) LIB(MYLIB) RMTLOCNAME(DEV)
OBJTYPE(*FILE)
This command copies an entire source physical file to the test system.
SAVRSTOBJ OBJ(QRPGLESRC) LIB(MYLIB) RMTLOCNAME(DEV)
Here's a command to copy one RPG source member, MYSRCMBR, from production to Development. Notice MBROPT(*NEW) was used here, because the source member did not already exist in QRPGLESRC on the Development system.
SAVRSTOBJ OBJ(QRPGLESRC) LIB(MYLIB) RMTLOCNAME(DEV)
OBJTYPE(*FILE) FILEMBR((QRPGLESRC (MYSRCMBR))) MBROPT(*NEW)
Another nice thing about the SAVRSTxxx commands is that they do not require enrollment in the system distribution directory, as SNDNETF (Send Network File) does.
Wednesday, October 3, 2007
Assertive Communication:
Do you have trouble saying NO, even when you really should?
Do you feel like people walk all over you?
Do you have trouble keeping your temper under control?
If you answered yes to any of the above questions, you might find it really helpful to learn about assertive communication.
I. What is Assertiveness?
Assertiveness is the ability to honestly express your opinions, feelings, attitudes, and rights, without undue anxiety, in a way that doesn't infringe on the rights of others.
It's not aggressiveness; it's a middle ground between being a bully and a doormat.
II. Why is Assertiveness Important?
If you don't know how to be assertive, you might experience Depression, Resentment, Frustration, Temper/violence, Anxiety, Poor relationships, Physical complaints and Parenting problems.
A note about selective assertiveness:
Most people find it easier to be assertive in some situations than in others. This makes perfect sense. It's a lot easier to hold your ground with a stranger than with someone you love who might get angry if you express your true feelings. But the more important the relationship is to you, the more important it is to be assertive.
III. Techniques:
How to be effectively assertive:
Use assertive body language. Face the other person, stand or sit straight, don't use dismissive gestures, be sure you have a pleasant, but serious facial expression, keep your voice calm and soft, not whiney or abrasive.
Use "I" statements. Keep the focus on the problem you're having, not on accusing or blaming the other person. Example: "I'd like to be able to tell my stories without interruption." instead of "You're always interrupting my stories!"
Use facts, not judgments. Example: "Your punctuation needs work and your formatting is inconsistent" instead of "This is sloppy work." or "Did you know that shirt has some spots?" instead of "You're not going out looking like THAT, are you?"
Express ownership of your thoughts, feeling, and opinions. Example: "I get angry when he breaks his promises." instead of "He makes me angry." or "I believe the best policy is to…" instead of "The only sensible thing is to …"
Make clear, direct, requests. Don't invite the person to say no. Example: "Will you please ... ?" instead of "Would you mind … ?" or "Why don't you … ?"
Do you feel like people walk all over you?
Do you have trouble keeping your temper under control?
If you answered yes to any of the above questions, you might find it really helpful to learn about assertive communication.
I. What is Assertiveness?
Assertiveness is the ability to honestly express your opinions, feelings, attitudes, and rights, without undue anxiety, in a way that doesn't infringe on the rights of others.
It's not aggressiveness; it's a middle ground between being a bully and a doormat.
II. Why is Assertiveness Important?
If you don't know how to be assertive, you might experience Depression, Resentment, Frustration, Temper/violence, Anxiety, Poor relationships, Physical complaints and Parenting problems.
A note about selective assertiveness:
Most people find it easier to be assertive in some situations than in others. This makes perfect sense. It's a lot easier to hold your ground with a stranger than with someone you love who might get angry if you express your true feelings. But the more important the relationship is to you, the more important it is to be assertive.
III. Techniques:
How to be effectively assertive:
Use assertive body language. Face the other person, stand or sit straight, don't use dismissive gestures, be sure you have a pleasant, but serious facial expression, keep your voice calm and soft, not whiney or abrasive.
Use "I" statements. Keep the focus on the problem you're having, not on accusing or blaming the other person. Example: "I'd like to be able to tell my stories without interruption." instead of "You're always interrupting my stories!"
Use facts, not judgments. Example: "Your punctuation needs work and your formatting is inconsistent" instead of "This is sloppy work." or "Did you know that shirt has some spots?" instead of "You're not going out looking like THAT, are you?"
Express ownership of your thoughts, feeling, and opinions. Example: "I get angry when he breaks his promises." instead of "He makes me angry." or "I believe the best policy is to…" instead of "The only sensible thing is to …"
Make clear, direct, requests. Don't invite the person to say no. Example: "Will you please ... ?" instead of "Would you mind … ?" or "Why don't you … ?"
Tuesday, October 2, 2007
Welcome the P-Field:
P-fields are one-byte codes that control the color and attributes of a field in a display file. Before P-fields were added to data description specifications (DDS), it was necessary for a programmer to make decisions about color and attributes during development. Whichever attributes were selected had to be included in the DDS. To apply different attributes to a field in different circumstances required the use of conditioning indicators.
In the following example, the NAME field is shown in blue. ADDRESS appears in white and will be underlined if indicator 11 is on. The color and attributes of the PHONE field depend on the setting of indicators 12, 13, 15, and 16.
A NAME 20A O 10 6COLOR(BLU)
A ADDRESS 20A O 11 6COLOR(WHT)
A 11 DSPATR(UL)
A PHONE 12A O 12 6
A N15N16 COLOR(BLU)
A N15 16 COLOR(RED)
A 15N16 COLOR(PNK)
A 15 16 COLOR(WHT)
A 12 DSPATR(RI)
A 13 DSPATR(UL)
It works, but it's hardly any fun.
P-fields allows to determine color and attributes at run time without using indicators. Load a P-field with a character in one of two ranges--hexadecimal 20 through 3F or hexadecimal A0 through BF--and the system takes care of the rest. These hex values and their meanings are listed under the discussion of the DSPATR keyword in the DDS reference. Notice that P-fields can't be used for attributes MDT (modified data tag), OID (operator identification), PC (position cursor), and SP (select by light pen).
In the following display file fragment, the NAME field's attributes are controlled by the value in the NAMEATTR field.
A NAME 20A B 10 6DSPATR(&NAMEATTR)
A NAMEATTR 1A P
Notice the usage entry of P for the NAMEATTR field. This tells the system that NAMEATTR is a P-field.
One way an RPG program might load a value into a P-field is by assigning a hexadecimal literal, like this:
nameattr = x'28';
The hex 28 value causes the field to blink on a dumb terminal and to be displayed in red on a not-quite-so-dumb terminal. That's not obvious enough. The source code will be more readable if we assign a named constant to the P-field, like this:
D Blink C Const(x'28')
NameAttr = Blink;
But the P-field value does not have to be hard-coded in the program's source code. It could be stored in a file or data area, passed into a program through a parameter, assigned a value according to user input, and so on.
P-fields are a superior alternative to indicators. Using P-fields with named constants that represent display attributes results in clearer code. P-fields can be stored in external objects like files and data areas or passed to a program through parameters.
However, that does not mean we should use P-fields only. Having to create a P-field for every data field on a display can get unwieldy. If a field always has a certain color or display attribute (it's always underlined, for example), it may not be worth the trouble to use a P-field. But for those times when you need more flexibility, P-fields are the way to go.
In the following example, the NAME field is shown in blue. ADDRESS appears in white and will be underlined if indicator 11 is on. The color and attributes of the PHONE field depend on the setting of indicators 12, 13, 15, and 16.
A NAME 20A O 10 6COLOR(BLU)
A ADDRESS 20A O 11 6COLOR(WHT)
A 11 DSPATR(UL)
A PHONE 12A O 12 6
A N15N16 COLOR(BLU)
A N15 16 COLOR(RED)
A 15N16 COLOR(PNK)
A 15 16 COLOR(WHT)
A 12 DSPATR(RI)
A 13 DSPATR(UL)
It works, but it's hardly any fun.
P-fields allows to determine color and attributes at run time without using indicators. Load a P-field with a character in one of two ranges--hexadecimal 20 through 3F or hexadecimal A0 through BF--and the system takes care of the rest. These hex values and their meanings are listed under the discussion of the DSPATR keyword in the DDS reference. Notice that P-fields can't be used for attributes MDT (modified data tag), OID (operator identification), PC (position cursor), and SP (select by light pen).
In the following display file fragment, the NAME field's attributes are controlled by the value in the NAMEATTR field.
A NAME 20A B 10 6DSPATR(&NAMEATTR)
A NAMEATTR 1A P
Notice the usage entry of P for the NAMEATTR field. This tells the system that NAMEATTR is a P-field.
One way an RPG program might load a value into a P-field is by assigning a hexadecimal literal, like this:
nameattr = x'28';
The hex 28 value causes the field to blink on a dumb terminal and to be displayed in red on a not-quite-so-dumb terminal. That's not obvious enough. The source code will be more readable if we assign a named constant to the P-field, like this:
D Blink C Const(x'28')
NameAttr = Blink;
But the P-field value does not have to be hard-coded in the program's source code. It could be stored in a file or data area, passed into a program through a parameter, assigned a value according to user input, and so on.
P-fields are a superior alternative to indicators. Using P-fields with named constants that represent display attributes results in clearer code. P-fields can be stored in external objects like files and data areas or passed to a program through parameters.
However, that does not mean we should use P-fields only. Having to create a P-field for every data field on a display can get unwieldy. If a field always has a certain color or display attribute (it's always underlined, for example), it may not be worth the trouble to use a P-field. But for those times when you need more flexibility, P-fields are the way to go.
Monday, October 1, 2007
Brainstorm:
Brainstorming is a technique used to quickly generate a quantity of creative or original ideas on or about a process, problem, product, or service. Brainstorming can be used to:
· Develop a vision
· Review inputs, outputs, and flows of existing processes
· Create a list of products or services
· Eliminate wasteful and redundant work activities
· Reengineer a process, product, or service
· Design a new or improved process
· Establish standards, guidelines, or measures
· Identify the internal and external customers served
· Improve the work environment
· Gather data for use with other tools
A brainstorming session begins with a facilitator establishing basic ground rules and a code of conduct. Typical brainstorming rules state that all members have an equal opportunity to participate, there is no criticism or pulling rank, people should think creatively, no idea will be treated as insignificant, and there should be only one conversation at a time. Members need to be active participants, willing to share their ideas, opinions, concerns, issues, and experiences.
Next the team agrees on the topic to be brainstormed and whether to give ideas verbally or written on individual index cards, or any other easily manipulated medium. Either a structured (round table) or unstructured (free-flowing) approach is selected. Ideas should be generated quickly (5-15minutes) and are recorded clearly on a flipchart or board. The process stops when ideas become redundant or infrequent. Recorded ideas are reviewed for duplication and clarification, and eliminated when necessary. Remaining ideas are then evaluated with an open mind and may be used with the affinity diagram, nominal group technique, or cause-and-effect diagram.
· Develop a vision
· Review inputs, outputs, and flows of existing processes
· Create a list of products or services
· Eliminate wasteful and redundant work activities
· Reengineer a process, product, or service
· Design a new or improved process
· Establish standards, guidelines, or measures
· Identify the internal and external customers served
· Improve the work environment
· Gather data for use with other tools
A brainstorming session begins with a facilitator establishing basic ground rules and a code of conduct. Typical brainstorming rules state that all members have an equal opportunity to participate, there is no criticism or pulling rank, people should think creatively, no idea will be treated as insignificant, and there should be only one conversation at a time. Members need to be active participants, willing to share their ideas, opinions, concerns, issues, and experiences.
Next the team agrees on the topic to be brainstormed and whether to give ideas verbally or written on individual index cards, or any other easily manipulated medium. Either a structured (round table) or unstructured (free-flowing) approach is selected. Ideas should be generated quickly (5-15minutes) and are recorded clearly on a flipchart or board. The process stops when ideas become redundant or infrequent. Recorded ideas are reviewed for duplication and clarification, and eliminated when necessary. Remaining ideas are then evaluated with an open mind and may be used with the affinity diagram, nominal group technique, or cause-and-effect diagram.
SQL Technique:
Extract ONLY n Rows from a table.
To limit the amount of results that a query may retrieve, the “FETCH FIRST N ROWS ONLY” is a useful technique:
SELECT * FROM TABLE_NAME
FETCH FIRST 10 ROWS ONLY
The last clause ensures that only 10 rows are fetched.
Method to simulate a "right-justify" for character data using SQL
There is no "right-justify" string function built into SQL, but it can still be done: Taking a character string of variable size and right-justifying within a target column
containing a maximum of 12 characters. The example below does a bit more but it illustrates well what can be done, effectively concatenating blanks (up to 12) for a length of 12 - the length of the source column.
INSERT INTO TARGET_TABLE
SITE_CODE_RIGHT_JUSTIFED
SELECT
SUBSTR(' ', 1, 12 -
LENGTH( TRIM( CHAR_COLUMN_NAME)))
|| TRIM( CHAR_COLUMN_NAME )
FROM TABLE
FROM SOURCE_DATA
To limit the amount of results that a query may retrieve, the “FETCH FIRST N ROWS ONLY” is a useful technique:
SELECT * FROM TABLE_NAME
FETCH FIRST 10 ROWS ONLY
The last clause ensures that only 10 rows are fetched.
Method to simulate a "right-justify" for character data using SQL
There is no "right-justify" string function built into SQL, but it can still be done: Taking a character string of variable size and right-justifying within a target column
containing a maximum of 12 characters. The example below does a bit more but it illustrates well what can be done, effectively concatenating blanks (up to 12) for a length of 12 - the length of the source column.
INSERT INTO TARGET_TABLE
SITE_CODE_RIGHT_JUSTIFED
SELECT
SUBSTR(' ', 1, 12 -
LENGTH( TRIM( CHAR_COLUMN_NAME)))
|| TRIM( CHAR_COLUMN_NAME )
FROM TABLE
FROM SOURCE_DATA
Agile Software Development Method:
Agile Software Development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. There are a number of agile software development methods; most attempt to minimize risk by developing software in short time boxes, called iterations, which typically last one to four weeks. An agile software project intends to be capable of releasing new software at the end of every iteration particularly when the software is web-based and can be released easily.
Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Agile methods produce very little written documentation relative to other methods.
Principles behind Agile methods
Some of the principles behind the Agile Manifesto are:
· Customer satisfaction by rapid, continuous delivery of useful software
· Working software is delivered frequently (weeks rather than months)
· Working software is the principal measure of progress
· Even late changes in requirements are welcomed
· Simplicity
· Regular adaptation to changing circumstances
Suitability of Agile methods
From a product perspective, agile methods are more suitable when requirements are emergent and rapidly changing; they are less suitable for systems that have high criticality, reliability and safety requirements.
The most important factor is probably project size. As size grows, face-to-face communication becomes more difficult. Therefore, most agile methods are more suitable for projects with small teams, with fewer than 20 to 40 people.
Agile development is expected to be particularly suitable for teams facing unpredictable or rapidly changing requirements.
Agile methods
Some of the well-known agile software development methods:
· Extreme Programming (XP)
· Scrum
· Agile Modeling
· Adaptive Software Development (ASD)
· Crystal Clear and Other Crystal Methodology
· Dynamic Systems Development Method (DSDM)
· Feature Driven Development (FDD)
· Lean software development
· Agile Unified Process (AUP)
Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Agile methods produce very little written documentation relative to other methods.
Principles behind Agile methods
Some of the principles behind the Agile Manifesto are:
· Customer satisfaction by rapid, continuous delivery of useful software
· Working software is delivered frequently (weeks rather than months)
· Working software is the principal measure of progress
· Even late changes in requirements are welcomed
· Simplicity
· Regular adaptation to changing circumstances
Suitability of Agile methods
From a product perspective, agile methods are more suitable when requirements are emergent and rapidly changing; they are less suitable for systems that have high criticality, reliability and safety requirements.
The most important factor is probably project size. As size grows, face-to-face communication becomes more difficult. Therefore, most agile methods are more suitable for projects with small teams, with fewer than 20 to 40 people.
Agile development is expected to be particularly suitable for teams facing unpredictable or rapidly changing requirements.
Agile methods
Some of the well-known agile software development methods:
· Extreme Programming (XP)
· Scrum
· Agile Modeling
· Adaptive Software Development (ASD)
· Crystal Clear and Other Crystal Methodology
· Dynamic Systems Development Method (DSDM)
· Feature Driven Development (FDD)
· Lean software development
· Agile Unified Process (AUP)
Subscribe to:
Posts (Atom)