Association Matrix Checklist

CHECKLIST FOR AN ASSOCIATION MATRIX
Project Name:		Project Code:
Document Name:		Document Number:
Reviewed By:		Reviewed Date:
Checklist Items		Yes	No	Comments
There are no missing rows or columns (the matrix is complete).
The rows and columns are sorted for best presentation.
All rows have an association with at least one column.
All columns have an association with at least one row.
For CRUD matrices, all entities that are being managed by the application have a "create".
For CRUD matrices, all entities that are managed by other applications (i.e., interfaces) show as "read" only.

i have to face problems, and solve them.

Reality

Reality of Life

Life isn't just full of happiness,
It's sunsets, it's love, it's tears.
It's the thoughts of yesterdays memories,
That can wash away all out fears.

It's that very painful experience,
That each one of us has had.
It's the laughter that fills the air,
It's the tears when you are sad.

It's loving that someone special,
That at one time made you smile.
It's the pain of losing that person,
But the memories that make it worthwhile.

It's that child in every one of us,
Although in time we'll all be old.
It's the good times we'll never forget,
It's the memories we'll always hold.

It's the hug that we all need,
When we'd rather drown in our sorrow.
It's the hope in every one of us,
That makes us hold on for tomorrow.

Using CRUD Diagrams to Group Processes into Systems

Using CRUD Diagrams to Group Processes into Systems

Grouping or clustering processes allows the analyst to identify what business processes fit naturally together. The groupings help determine what functions a specific system should perform and what data it requires.

The objective is for groups to have a high degree of independence from one another.

Converting to Association Matrix may Simplify Grouping

Grouping processes does not distinguish between create, read, update, or delete. Therefore, it may be simpler to convert the CRUD Diagram to an Association Matrix by changing each intersection with a C, R, U, and/or D into a common symbol such as a check mark or an asterisk.

Example: CRUD Diagram Converted to Association Matrix

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Receive Customer Order	*	*	*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Maintain Customer Account	*		*		*
Terminate Customer Account	*		*		*
Pay Vendor Invoices					*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Invoice Customer	*		*	*
Maintain Inventory						*

Initial Grouping

Begin by identifying the first two processes that use the same data entities. Rearrange the rows to position these two processes at the top of the matrix.

Identify other processes that use the same data entities and, if any, move them into the next rows in the matrix.

Example: Initial Grouping of Processes

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Maintain Customer Account	*		*
Terminate Customer Account	*		*
Receive Customer Order	*	*	*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Ship Customer Order			*		*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Invoice Customer	*		*	*
Maintain Inventory						*

Continue Grouping Process

Continue to identify other sets of processes that share the same data entities and move them into the next rows.

Example: Next Grouping of Processes

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Maintain Customer Account	*		*
Terminate Customer Account	*		*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Receive Customer Order	*	*	*
Ship Customer Order			*		*
Invoice Customer	*		*	*
Maintain Inventory						*

Manual Grouping

Once all processes that use the same entities have been identified, begin to analyze remaining entities to determine their best fit. This analysis is subjective. In the example you may decide that Receive Customer Order and Invoice Customer should be grouped with Process Customer Order and Fill Customer Order because they are all involved in processing the customer's order.

Example: Manual Grouping of Processes

Entity Process	Customer	Customer Order	Customer Account	Customer Invoice	Vendor Invoice	Product
Maintain Customer Account	*		*
Terminate Customer Account	*		*
Receive Customer Order	*	*	*
Process Customer Order	*		*			*
Fill Customer Order	*		*			*
Invoice Customer	*		*	*
Ship Customer Order			*		*
Validate Vendor Invoices					*
Pay Vendor Invoices					*
Maintain Inventory						*

Consider Using Subject Databases

Entities may be grouped into subject databases using a method such as Affinity Analysis. The subject databases are then used on the matrix instead of data entities. Grouping processes will be easier when there are fewer objects to analyze. For example, Customer, Customer Order, and Customer Account may be grouped as Customer while Customer Invoice and Vendor Invoice may be grouped as Invoicing.

Example: Grouping Processes using Subject Databases

Subject Process	Customer	Invoicing	Product
Maintain Customer Account	*
Terminate Customer Account	*
Receive Customer Order	*
Process Customer Order	*		*
Fill Customer Order	*		*
Invoice Customer	*	*
Ship Customer Order	*	*
Validate Vendor Invoices		*
Pay Vendor Invoices		*
Maintain Inventory			*

Craig Borysowich (Chief Technology Tactician)

what did you say

Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale
Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale

Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale

Duniya Jo Pooche To Kya Hum Kahen
Koi Yeh Humko Samjaade
Thes Lagi To Pal Mein Toot Gaye
Sheshe Ke The Kya Sab Vaade
Jaata Hai Koi Kyon Sapno Ko Thukraake
Payega Yeh Dil Kya Kisi Ko Batake
Chalte Chalte Raakh Hum Bin Jale Ho Gaye
Bujh Gaye Diye Pyaar Ke
Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye

Doob Gaya Hai Kaise Dard Mein Dil
Aansoon Bhari Hai Ab Aankhen
Tanhaiyon Ki Jo Ruth Aa Gayi
Ujdi Hui Hai Sab Raahein
Socha Tha Paayenge Dono Ek Manzil Ko
Raahein Jo Badli To Tumhi Batado
Chalte Chalte Gum Kahan Kaple Ho Gaye
Kho Gaye Kahan Raste
Pyaar Hum Ko Bhi Hai
Pyaar Tum Ko Bhi Hai
To Yeh Kya Silsile Ho Gaye
Bewafa Hum Nahin
Bewafa Tum Nahin
To Kyon Itne Gile Ho Gaye
Chalte Chalte Kaise Yeh Faasle Ho Gaye
Kya Pata Kahan Hum Chale
Kya Pata Kahan Hum Chale

Do I Even Need a Prototype??? & Prototyping Overview

Prototypes can add unnecessary overhead if they are not needed or are not workable for a particular project situation. Analyze the circumstances of the project to determine if a prototype will add value. When making the decision, consider the benefits of prototyping.

THE BENEFITS OF PROTOTYPING

Types of Benefits

Prototyping primarily assists with communication between the end-user and the development staff. The enhanced communication results in greater accuracy and fewer errors in later parts of the project, when they become more expensive to fix. The early involvement also empowers the end-user and facilitates system acceptance and understanding.

Communicate Requirements to Customer

Prototyping is an effective means of communicating the analyst's understanding of system requirements to the customer. The customer achieves a better understanding of the proposed system than could be obtained from written documentation alone. Therefore, problems that may have gone undetected until a later stage are identified earlier.

Prototyping should be used for all interactive systems. Consider that a serious review by end-users will almost always result in a change.

Communicate Requirements to Programmer

Prototyping is an effective means of communicating the system requirements and design to programmers. It is easier for the programmers to build a system from a working model than from a design document.

Customers See the Design at an Earlier Stage

Some design activities, such as Human Interface Design, occur at an earlier stage in the life cycle when a prototype is developed. Customers are able to try out the design and provide their input before much time and money are expended.

If Horizontal Prototyping is used during analysis, a first cut of the system externals is defined at that time. If a Vertical Prototype is developed, a first cut of the database must be designed during analysis.

Prototyping can greatly reduce the scope and size of design activities. Design activities still occur but they are moved to other stages of the system life cycle. Depending on the extent of the prototype, design efforts can be reduced to include only such tasks as test plan preparation, user aids design, conversion design, and database optimization.

Greater Customer Involvement

Customers become more involved in the system development process when a prototype is used. This helps ensure that customer requirements are met.

Reduce Written Documentation

Prototyping makes a system more intuitive and reduces the amount of written documentation required.

Situation Where Prototypes are Most Valuable

Some situations where prototyping is particularly valuable include:

· scope of the project permits customer involvement to improve the system,

· customers are unsure of their exact requirements or are having difficulty expressing requirements,

· the new system is altering a basic business operation,

· customers are not fully aware of all the impacts of the new system,

· the advantages and disadvantages of alternative solutions need to be explored.

Situations For Limited Prototyping

In general, prototyping is more valuable for on-line systems than for batch processing. However, most batch systems produce reports which can be prototyped using a report generator. Prototyping is of limited value in some systems that are logic intensive. In these cases, horizontal prototypes can still be used to evaluate the human interface.

Craig Borysowich (Chief Technology Tactician)

-------------------------------------------------------------------------------------

Use Prototyping to:

· develop a working model of key functional components of a system, which may or may not be developed into the final system,

· enhance communication of requirements between the analyst, customer, and development team members,

· demonstrate features of the proposed system to such a level that the customer can relate it to his or her requirements,

· allow customers and analysts to explore alternative architectures and specific customer task scenarios,

· uncover design flaws early in the project life cycle,

· train customers who will eventually use the system,

· validate customer requirements (are we building the right product?),

· verify customer requirements (are we building the product right?).

Method

To build a prototype, complete the following steps:

Evaluate the Need for Prototyping

Define the Type of Prototype

Develop the Prototype

Refine the Prototype

Tips and Hints

Fourth Generation tools make it possible to quickly and easily prototype a model of system externals. However, if the prototype cannot be built and changed easily, many of the advantages of prototyping are lost. Some tools require considerable effort to set up the database or make database changes, particularly in the hands of inexperienced programmers.

See Also

Interviewing (for defining requirements related to the external design of a system)

Participant Observation (for defining requirements related to the external design of a system)

Timeboxing

Craig Borysowich (Chief Technology Tactician)

Developing & Implementing Training & Education Programs

To develop or acquire training and education programs to satisfy employee training requirements.

Understand Training Requirements

Review existing support material (e.g., policy and procedure manuals, forms, reference material, equipment and facilities, work sites, job specifications/descriptions, current training material). Interview subject matter specialists to ensure/confirm understanding of material and requirements.

Define Training Objectives and Evaluation Process

Identify performance, skill level, and knowledge required at the end of training. Estimate training time frame and cost in person-days and funds. Define the process that will be used to evaluate the effectiveness of the training (e.g., testing, simulations, problem solving, interviews).

Measure Pre-Training Performance Level

Develop evaluation exercises (e.g., true or false/multiple choice questions, short answers/essays questions, simulations (role playing), oral interviews). Measure current performance of training audience and select participants to be trained.

Evaluate Off-the-Shelf Training/Education

If training requirements are generic (e.g., personal development training, management training, technical training) research and evaluate off-the-shelf training solutions (e.g., courses from companies specializing in specific types of training, technical school/college courses, university courses).

Select Delivery Mode and Instruction Strategy

Select the best approach for training participants (e.g., instructor led training, computer based training, on the job coaching, simulations, workshops, self-paced learning, just-in-time training, off-the-shelf training/education).

Design Custom-Specific Training Material

Develop a detailed outline (e.g., lesson, topic, session) of training courses including sequence of instruction, content to be covered by each topic, paths through training, and approach for each topic, exercise, and workshop. If training will be delivered using multimedia (e.g., computer, video, audio), design each segment type (e.g., screens, menus, scripts, visuals) in the course and prototype (e.g., storyboards, scripts, animations, soundtrack, graphics) key content.

Validate Custom-Specific Training Design

Validate the training design by conducting walk-throughs with subject matter specialists.

Develop Custom-Specific Training Material

Create training material including student workbooks/handouts, instructor guides, visual aids (e.g., foils, slides, graphics), multimedia material (e.g., audio, video, graphics, animation, text), exercises, workshops, simulations, and case-studies.

Tips and Hints

An organization that specializes in developing customized training should be used if custom development is substantial.

IMPLEMENT TRAINING AND EDUCATION PROGRAMS

Purpose

To deliver and support the training and education programs.

Setup Training Environment

Set up and maintain the training environment (e.g., facilities, equipment, hardware, system software, application software, application data).

Administer Training Support Material

Schedule courses, students, and instructors. Administer course material (e.g., student workbooks/handouts, instructor guides, visual aids, multimedia material) and supplies (e.g., name tags, paper, pencils, refreshments). Contact students and instructors. Manage travel and living accommodations.

Pilot Training

Test training program using a cross-section of students. Identify issues with content, logistics, material, and delivery method. Prioritize problems and identify solutions. Revise content and materials and address logistical issues.

Conduct Training Sessions

Conduct training sessions. Monitor sessions and identify issues. Prioritize problems and identify solutions. Revise content and materials and address logistical issues.

Evaluate Effectiveness of Training

Evaluate the effectiveness of the training and education program. The post-training evaluation exercise should measure the same skills and knowledge level as the pre-training evaluation exercise. It is not necessary to evaluate every student or every course offering. An evaluation must be performed:

· when a new course is given or significant changes are made to an existing course,

· when significant problems have been identified with an existing course,

· when a new instructor is teaching,

· on an ongoing basis to a random sampling of courses.

Craig Borysowich (Chief Technology Tactician)

Programming is NOT an art

I have been quiet lately as I work on some larger bits of writing, but some posts today can't be ignored, mainly "Programming as a Fine Art".

Have you read it? If so, let it be known that I vehemently disagree with the idea that programming is an art. I got paid to be a programmer for a number of years, and never did I feel artistic. I did some new, cool stuff on some projects, and did grunt work on others, as described in the above article. An essential word that is passed by quickly in the article is "craft". Craftsman create things that are to be used; they may be decoratively ornate - think of antique furniture you see on Antiques' Roadshow - but that is to make the object more appealing to potential buyers.

Software is created to be used. Anything that is considered Art is not that pedestrian; Art is intended to communicate, inspire, provoke and all that, I don't see the NEA (U.S.)sponsoring software development, and don't expect software to ever be banned in Boston.

Another essential word in the article is 'engineering', as in software engineering. Engineering is defintely not Art, it is applying methods to solve real-world problems with solutions that don't fall down (like bridges) or fail to work (like software). In fact, reaching an actual Engineering level of discipline for software is something we should aspire to, leaving craftsmenship behind, as happened in the Industrial revolution with manufacturing plants putting craftsman out of work.

I know this article is about why the teaching of programming is suffering in the wider discipline of Computer Science, but treating it as a 'liberal art' is not the solution. If programming is going to continue to be a craft for some time to come, then the classic apprenticeship approach is the way to go. Although I was Computer Science grad, that is how I started. My first employer knew that grads of other disciplines could also be candidates, so it had a programming evaluation test for applicants. If you passed it, the company believed you had the skills to program ,and I enede up working with many people with other degrees like law.

In the end, a university degree shows that a person can learn; the specifics of what they studied may or may not be useful in their careers. So, companies should be looking for people willing to learn programming, rather than expect them to already know how.  

Busy Schedules & Interviewing

Busy Schedules & Interviewing

Someone recently asked me to write a BLOG on how those employed by Big Five and high-travel consulting roles can find time to interview with their high travel requirements. This is a great question and a topic that I deal with quite often. I believe some of my ideas below may help.

First, I recommend that people are very serious when they decide it is time to begin interviewing. Meaning, that the job seeker has already spoke with their current employer or supervisor about any important issues that is causing the person to consider making a move. When it is 100% clear that a career change is mandatory, people seem to find a way to prioritize their schedule and find time to interview.

Secondly, I recommend that people do a phone interview first to ensure that you really are excited about the company, the role, the responsibilities, and the person you'll be working with. You are interviewing the client as well! Phone interviews are easier to squeeze in before 8 AM; during lunch; and in the early evening if both parties realize the importance.

Third, I recommend that you fully research the company on your own using the internet, industry contacts, trade journals, etc. Do all of your homework before investing your own time and the time/money of a company that is also in your industry. By not wasting their time, you won't burn future bridges in a very small world!


Consultants usually travel Monday thru Thursday and can often interview on Fridays in their home town. Some companies are open to interviewing on weekends as well.

When all else fails, the next three best options for high-travel Big 5 consultants is to do a Video Conference Interview with the client (your local Kinko's); schedule it 1-2 weeks out and take a vacation around a 3-day weekend; and finally make creative suggestions like starting you as a consultant in a "Right to Hire". I've even had hiring managers fly to the "job seekers' location and I've heard of executive recruiters video taping an interview and mailing it to the manager.

I hope these ideas help you to consider some other options as we try to fit interviews into an already hectic professional work schedule! Good Luck.

SAP talent agent (IT Recruiter, MRI)

world is like child play infront of me

1.      baazeechaa-e-atfaal hai duniya mere aage
hota hai shab-o-roz  tamaasha  mere aage

[ baazeechaa = play/sport, atfaal = children ]

2.      ik khel hai auraNg-e-sulemaaN mere nazdeek
ik  baat  hai 'eijaz-e-maseeha  mere  aage

[ auraNg = throne, 'eijaz = miracle ]

3.      juz naam naheeN soorat-e-aalam mujhe manzoor
juz waham naheeN  hastee-e-ashiya  mere aage

[ juz = other than, aalam = world, hastee = existence,
ashiya = things/items ]

4.      hota hai nihaaN  gard  meiN sehara mere hote
ghisata hai jabeeN KHaak pe dariya mere aage

[ nihaaN = hidden, gard = dust, sehara = desert, jabeeN = forehead ]

5.      mat pooch ke kya haal hai mera tere peeche ?
too  dekh  ke  kya  rang  tera  mere  aage

6.      sach kahte ho, KHudbeen-o-KHud_aaraa na kyoN hooN ?
baiTha   hai   but-e-aainaa_seemaa   mere    aage

[ KHudbeen = proud/arrogant, KHud_aaraa = self adorer,
but = beloved, aainaa_seemaa = like the face of a mirror ]

7.      fir dekhiye andaaz-e-gul_afshaani-e-guftaar
rakh de koee  paimaanaa-o-sahba  mere  aage

[ gul_afshaanee = to scatter flowers, guftaar = speech/discourse,
sahaba =  wine, esp. red wine ]

8.      nafrat ka gumaaN guzare hai, maiN rashk se guzaraa
kyoN  kar  kahooN,  lo  naam  na  uska  mere  aage

[ gumaaN = doubt, rashk = envy ]

9.      imaaN mujhe roke hai jo khiNche hai mujhe  kufr
ka'aba   mere  peeche  hai  kaleesa  mere  aage

[ kufr = impiety, kaleesa = church/cathedral ]

10.     aashiq hooN, pe maashooq_farebee hai mera kaam
majnooN  ko  bura  kehti  hai laila  mere aage

[ farebee = a fraud/cheat ]

11.     KHush hote haiN par wasl meiN yoN mar naheeN jaate
aayee   shab-e-hijaraaN  ki   tamanna   mere  aage

[ hijr = separation ]

12.     hai mauj_zan ik qulzum-e-KHooN, kaash, yahee ho
aata  hai  abhee  dekhiye  kya-kya   mere  aage

[ mauj_zan = exciting, qulzum = sea, KHooN = blood ]

13.     go haath ko jumbish naheeN aaNhoN meiN to dam hai
rehne   do   abhee  saaGHar-o-meena   mere   aage

[ jumbish = movement/vibration, saaGHar-o-meena = goblet ]

14.     ham_pesha-o-ham_masharb-o-ham_raaz  hai mera
'GHalib' ko bura kyoN kaho achchaa mere aage !

[ ham_pesha = of the same profession, ham_masharb = of the
same habits/a fellow boozer, ham_raaz = confidant ]

21 rules of negotiation

The Critical Rules

Rule 1: No free gifts! Seek a trade-off (“OK, if . . .”) for each concession you make.

Rule 2: Start high.

Rule 3: Follow a dramatic initial concession with sharply diminishing concessions.

Rule 4: Krunch early and often.

Rule 5: Never settle issues individually. Settle all issues as a package—only as a package—at the end.

Rule 6: Conclude with a nibble.

Rule 7: Keep looking for creative (high value–low cost) concessions to trade.

7. The Important but Obvious Rules

Rule 8: Do your homework.

Rule 9: Keep the climate positive.

Rule 10: Never assume that an issue is non-negotiable just because the other side says it is. In reality, almost everything is negotiable.

Rule 11: Never accept the other side’s first offer.



8. The Nice to Do Rules

Rule 12: Start slowly.

Rule 13: Set a complete agenda.

Rule 14: Discuss the small things first.

Rule 15: Be patient.

Rule 16: Use/beware the power of legitimacy.

Rule 17: Keep your authority limited. Try to negotiate against people with higher authority.

Rule 18: Consider using good guy–bad guy.

Rule 19: Try to have the other side make the first offer.

Rule 20: Keep your team small and under control.

Rule 21: Try to have the other side travel to you.