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.

5.2 Structured Design VS Object Design

Structured design was developed in 1970s to deal with complex information systems which have many different functions. Structured design uses structure chart as main primary modeling technique to provide guidance for deciding what set of programs should be, what each program should achieve and how each program should be organized in hierarchy.

Structured design describes functions and subfunctions of each part of system, it shows relationship between modules of a computer program uses two main concepts of coupling & cohesion to structure and organize modules. Detailed explanation of these modules are explained in the next posts.

Structured design assumes the designer knows what the system needs to do & what the main functions are, what are inputs and outputs therefore a key aspect of user-interface is done in conjunction with structured design especially after the database is used in the system and users have to interact with it.

The weakness of structured design is that it only addresses some but not all of the activities in analysis and design which makes it more like an art where people like more comprehensive & rigorous technique like engineering principles. Another weakness of structured design is the transition from DFD to structured chart didn’t work well on the other hand many believed that data modeling is more important than process modeling – in structured analysis & design process is centre of focus of system.

Object oriented approach views system as collection of interacting objects that work together to accomplish tasks therefore conceptually there is no data entities or files, no program or process. OO design defines all kinds of objects necessary for communication, showing how objects interact to complete tasks and refining definition of each object so it can be implemented with specific language or environment.

Two main important models used in OO design are design class diagram and interaction diagram. Class diagrams are developed for domain, view & data access layer. Interaction diagram extend system sequence diagram.

As said; in OO approach it's only objects and they send each other messages to collaborate and support functions of main program.

According to Rob (2004) :" The steps of developing a system (planning, analysis, design, implementation) do not change but how they are performed can be different."

In structured Approach we use DFD, in OO approach we use Use Cases. likewise; in structured approach design of system components i.e. input, output, modules of program and DB are evolved from DFD. In OO approach we use UML and there is no clear-cut step and no single model that components evlove from it.

In practice, organisations use combination of structured and OO approach however Rob (2004) believes that in the era of OO programing, OO modeling and OO design is desired and mixing up structured methodology & OO methodology can be confusing. He believes we need clear definition of models and steps as an analyst moves from the activities of analysis to design to implementation.

REFERENCES:

* Systems Anslysis And Design in a Changing World - SJB

* Rob Mohammad A., (2004). "Issues of Structured VS. Object-Oriented Methodology of System Analysis and Design". University of Houston-Clear Lake.

Task 2.3

we have a team of four;

I, Sia, am in the 3rd year studying double major, Information Management & Information Systems.

I guess it's a bit early to say if the team is good or not at this point since we haven't started working and we haven't done anything yet a good team should be flexible and have multi dimensional skills, it's impossible for a person to have all the skills and that's why we make teams - to achieve something more than a person can achieve!

Technical skills of team is only one part a good team; soft skill, communication and how to resolve conflict (if happened) are more important and make teams more effective.

Most of the decisions are made by consensus however if the subject was the area of expertise of a member, of course that member's opinion carries more weight.

Most of the communication is done by email. But other tools such as Google docs is used for collaborative works. of course there are face-to-face meetings when instant feedback or some discussions are necessary.

Task 2.1

This in fact was - and maybe is since it is not complete yet - a very cumbersome task. I had very difficult time normalising the database since I forgot most of the things about normalisation. Honestly I really didn't understand why we have to do this huge task in SDI, this would be more suitable for the database subject, however there were good points about why different database structure is needed for different purpose in organisations which I think is a realistic situation in regards to answering if the task was realistic or not.

As mentioned in the studio, different database structure suits different purpose e.g. for BI purpose or transactional database and they vary in terms of performance or ease of use so re-structuring database seems necessary in order to change the database to suit the purpose.

whether it's done in the way we did or not i.e. manually by hand or by some tools is the answer which I like to know as feedback, however it doesn't seem wise to do it manually unless there is no tool to perform the action.

1.3 Growing Up: Moving from Technology-Centered to Human-Centered Products

In the early years of computers or better to say computer systems, factors which users appreciate and determined value of system differed significantly. That time the only important aspect of system was to be proven sufficiently great regardless of cost & clumsiness.

Changing & improving capabilities of technology has made significant impact on people's expectation from systems. At the beginning, people used to buy technology for the sake of technology, they had single device for every single function, these people are known as early adopters. At that stage the only important factors were quantitative factors and other factors such as ease of use, productivity, usability etc were always neglected.

When technology becomes mature, we take it for granted. We no longer seek same factors in evaluating their values. for example in early ages of computing, the most important thing was to ensure that computers are working and are reliable, now a days no longer people seek these characteristic since they all work reliably most of the times, now it's important to have same product with same features & performance for less price.

As the computers become more mature, some aspects are taken for granted such as performance, functionality and reliability which were the subject of interest of early adopters who had high technological skills but new computer users are paying more attention to cost, ease of use, physical attractiveness and prestige. So as technology becomes mature it moves to background i.e. technological aspect of product loses importance and on the other hand things such as emotion becomes more important to developers to make the system a real consumer-product. When first a technology is introduced, only people who are high-tech will buy and use product who only care about technological aspect but when the product reaches to a point where it satisfies performance and technological aspect new consumer enter the market and use the technology who take the previously mentioned criteria for granted and with different expectations.

One big problem here is that satisfying these two kinds of consumers requires completely different approach – paradoxical approach!

If a product wants to be successful, the company needs to focus on three aspects;

• Technology: to meet performance, functionality and other technological aspect of product. It's the technology that makes things happen - without proper technology non of these things can happen. The Xerox Star & Apple Lisa are two example that didn't have proper technology although they met some other criteria.
  

• User experience: to meet and satisfy user and their expectation of the system. There might be some conflicts with marketing; marketing tend to focus on customer but UE tend to focus on users of the system.
  

• Marketing: to remain in the market with reasonable price. Marketing needs to understand who are customers, what are their expectations, why they buy the product and how much they are willing to pay. One thing that companies need to distinguish is the difference between customer(a person who pays and buys the system but not necessarily uses it) and user (people who touch the system and use the system). People buy product based on perception but the reality so it's very critical to place the product in the right place in the market
  

1.2 Memo to Anne & Elizabeth

Dear Anne,

Following our coffee meeting regarding to establishing a online retail shop, here is a brief outline you should approach.

First of all, regarding the domain name; I should say obviously an easy-to-remember domain name will help a lot since people can remember it easier. It will facilitate advertising however what distinguishes you in the dynamic world of the Internet where other shops are just a click away are good price, quality of service, short response time and website's usability and ease of use.

Since you are just stating the business - which is very small in size - it's not smart idea to have dedicated IT staff to develop an eCommerce system and maintain it. While developing systems internally have some advantages like meeting specific needs and high customisation, it is so expensive and takes lots of time which is not advisable for a small retail shop at this size.

At this stage, you as a retail shop have very generic needs which can be met by available eCommerce software packages, not to mention that these software packages can be customised to some degree based on the nature of the business you're doing (haircare industry in this case) to meet some of your specific needs and has templates and pre-designed features that can be added as you need them.

Considering your current circumstances - a new small business without any IT staff and with limited budget - the main advantage of this approach for you is its short implementation time, and having experts implementing the system, lower development cost and having maintenance available staff available to you.

Kind regards,

Siavash

1.1 About ODBC & SQL

it's desired to have one single database in organisations, but there exist more than one applications - in fact there are multiple applications in organisations which access the database and draw data when they need it.

Applications in order to access the database need a connection, this connection of course can be established in many ways. ODBC aims to provide a standard way using SQL to connect different applications such as MS Access, MS Excel, dynamic web pages or other applications such as data mining tools (e.g. WizRule). So if applications want to get data which doesn't exist on their HDD, first they need connect to the relevant database, ODBS provide this connection; once this connection is established any application can access to the database without establishing the connection again. So the connection is only established once but depending on the setting of the system authentication is required.

As said ODBC access database by SQL which is a DBMS language for programing and structuring language.

According to Wikipedia ODBC includes two parts:
1. the driver manager which works as an interpreter between database & applications.
2. the database driver which includes details of the database itself.

fist written on: July 14, 2008

FIT2027 - SDI

This is not a post for assessment, I just wanted to say that I started blogging for my new subject FIT2027 - Systems Design & Implementation. I didn't create a new blog, I use my old systems analysis & design blog for the same purpose...