My main blog changed!

Yeah for the time being I'm gonna do blogging on Wordpress!

So if you feel like catching up with my stuff: http://salvn.wordpress.com/

~peace

Sia

Starting point for Data Warehousing

First post on first day of March, for first time in 2O1O!

This is my first blog for data wareshoung though you can hardly call it a post since it may not have any significant academic value...

It's just a mini blog to show that I'm keen to keep blogging for this subject as part of my course in Uni. Last semester I had Business Intelligence unit & I didn't do any blogging for that - regretting now - but for this subject I do my best to pick a specific topic and post something not only to get extra mark if possible but to learn something truly for myself...

Ancora Imparo!

9.1 Ten Tips for Testing

Levison believes testing is very really vital for success of any project, testing evaluates whether requirement criteria are met or not, functions and features are working properly so it's usable. In addition testing not only improves the quality of testing itself but insures the quality of the software.

Levison gives the following testing tips to have a successful & effective testing in organisations:

1. Choose testers carefully; testing is a very cumbersome task and needs great patience with focus on details of codes so employ people who are good at coding and programing & who can understand nature of job well. Often testing is overlooked since it's a entry level job.

2. Let testers know how much important and valuable they are, many testers don't know the value of what they are doing and what can be achieved as result of their work> increase the knowledge of how important they are by publishing what has been saved in different companies and industries as result of testing and discovering defects and fixing them.

3. Co-locate testers and developers; this improves communication between them. pay attention to physical proximity between them considering they usually have conflict with each other since the job of testers are to find faults of developers.

4. Cross-train developers and testers; this is a very effective way to foster communication and understanding between these two groups, consequently the relationship between these 2 groups will be improved as well.

5. Encourage programmers to chill out and relax; programmers are very sensitive to what testers say and do. Developers put too much effort in programming and do their job enthusiastically and think they've just done great so they cannot tolerate what testers say since at the end they are (developers) the people who will be blamed for errors and problems. But let developers know that testers are just doing what they are being paid for and performance reviews are not purely based on what testers say.

6. Set up independent reporting structure; don't have testers report to development group. This will lead to developers keep testers out of the loop in a situation where developers are having problems or are behind schedule.

7. Centralise testing groups; centralising them into one group rather than according to application area ensures they are sharing best practices and lessons learned. Otherwise testers will use their own methodologies in each problem area and communicating lessons learned from projects will be much harder.

8. Dedicate testers to specific systems. divide testers into groups and assign each group into one function e.g. warehouse, finance systems, etc. This will deepens their understanding of that system, also gives them expertise to identify problems that may not show up in a test document.

9. Give testers business training so they can have better understanding of the system.

10. Involve users in testing; this ensures that the system meets their requirements & specs.

4.4 UML Tutorial

Hey all!

this is a very brief tutorial on UML, I hope you find it useful.
Click to UML Tute watch the tutorial.

5.5 Cohesion

Partitioning system & how clearly modules are separated from one another is called coupling. Cohesion is how activities within a single module are related to one another. These two are important for measuring partitioning & interdependent.

Designers should create strong, highly cohesive modules that is the elements of one module should not be strongly related to another module. Here are some characteristics of good & bad cohesion:

• Functional cohesion

Functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task e.g. read transaction record. Another example is calculate net employee salary which is a very complicated module and has may sub-functions but if you can sum up everything it accomplishes as one problem related function, then it’s functionally cohesive.

However there are many jobs that cannot be summed up as a single problem-related function. In this case the level of cohesion depends on how different activities are related to one another. Functional cohesion is the easiest and cheapest type of cohesion.

• Sequential cohesion

Sequentially cohesive modules are those with elements involved in activities that output from one activity serves as input to the next. Advantage of sequential cohesion is good coupling on the other hand not being able to re-use it can be seen as disadvantage. Not to mention that the order of carrying out activities are important in sequentially cohesive modules and more importantly just data flow from one module to another not the control.

• Communicational cohesion

Refers to cohesion between modules which use same input or output. The problem of communicational cohesion is the temptation to share code among activities within that module as result change in part will destroy other parts of module.

• Procedural cohesion

Higher level of cohesion where elements of modules are involved in different and possibly unrelated activities in which control flow from each activity to the next. In this kind of cohesion, control flows from one module to another. These kinds of modules are composed of functions that have little relationship to one another.

• Temporal cohesion

Modules with elements that are involved in activities that are related in time but activities may have no relationship among themselves.

• Logical cohesion

Modules which their elements contribute to activities of same general category in which activities to be executed are selected from outside the module. So in this kind of modules there should be a specific thing which is shared among all of them.

• Coincidental cohesion

Modules those their elements contribute to activities with no meaningful relationship to one another so it’s a bit similar to logically cohesive modules. Activities here are related neither by flow of data nor by flow of control.

There are different ways to determine level of cohesion of a module; one way is to write a short sentence that accurately, honestly, and fully names modules and their functions. These sentences will reveal the level of cohesion among modules. Another way is by drawing decision tree

5.4 Automatic Transformation from Data Flow Diagram to Structure Chart

Moving from structured analysis to structured design is a very challenging task in terms of both complexity and correctness. One of the tools which can assist us is CAST (Computer-Aided Structured Transformation) which automatically translates requirement specs to design specs.

CAST accepts DFD diagram as input – the diagram which we already use for software requirement specification. CAST consists of:

• Description language:

• Rule base: contains info on structured design methodology to help which methods should be applied

• Automatic transformation system: helps with intelligent decision making to determine suitable architectural design.

Structured system development consists of notations such as DFD which represents processes and data. In this kind of system development (structured) lower levels represents composition of higher level. These are the most important diagrams in analysis & design & implementation phase: DFD in analysis and structured chart for design & implementation which provides basis for evaluating coupling & cohesion.

When converting diagrams to descriptive language; DFD is decomposed into 5 components: source, sink dataflow, process & file. Structured chart is represented in modules, structure & relation.

Additionally for structure chart transform & transaction analysis are used.

In transform analysis input & output from DFD helps us to determine the central portion of system responsible for transforming data. In this type of analysis, DFD contains: transform centre which is centre of collection of processes which make up major functions of system, afferent stream which starts by reading from physical source & converts it to some suitable form for transform and efferent stream which converts the data from transformation centre to more physical form for output to real world.

In transaction analysis we try to isolate transaction centres which capture transactions by determining their types and then sending them to appropriate branch.

5.3 Moving into Design

Like the analysis phase, there are also models in the design phase most important of them are system implementation model (includes processor model & task model) and program implementation model.

Processor model aims to allocate essential models to different CPUs and how CPUs should communicate among themselves e.g. entire essential model can be allocated to a single processor or each bubble in DFD can be allocated to a different CPU. Data stores should be allocated to different processors as well.

In any of the cases which more than 1 CPU is used, communication mechanism among CPUs should be considered. This communication can happen by direct link between processors with a cable or channel or LAN or indirectly by writing to a magnetic type or anything which can be read by another processor as input.

A very important issue to be considered is that communication between processes (bubbles) is much much faster than CPU-to-CPU communication therefore system designer should group processes & stores to have high volume of communication within each process. Of course other factors such as cost, efficiency, security and reliability should be considered too.

Task model aims to assign tasks & data stores to individual tasks on each processor. All the terms partition, job step, overlay or control point implies the notion of task. The types of activities (synchronized or asynchronized) have impact on processors’ activity as well.

The program implementation model

At level of each individual task where usually only one activity can take place at the same time, program implementation model is used to organize activities of a single unit in structured chart.

Two of the most design goals and objectives are high cohesion and low coupling as well as other objectives such as module size, span of control and scope of effect/scope of control:

Cohesion: the degree to which components of a module are sufficient and necessary to carry out one single well-defined function. Essential processes shouldn’t be split to different modules and no unrelated tasks are gathered in a module. High cohesion is desired which means each module carries out one single task.

Coupling: the degree to which modules are interconnected or related or linked to one another. Strong coupling between modules i.e. high level on communication between modules in system makes the system complex & difficult to implement and maintain. Also a change in one part of a system may have unpredictable effect in another part of the system. Low or loose coupling is desired which means keeping modules small, simple with minimum number of data element shared between modules.

Span of control refers to number of immediate subordinates that can be called by manager module. To increase span of control an intermediate level of manage module can be put in place

Scope of effect/scope of control: refers to how much a module is dependent or affected by outcome of decision of other modules. If this is the case, the module should be subordinate to the module that makes decision.