Saturday, August 31, 2019

Critical Essay of Mark Twain’s “The Damned Human Race”

Mark Twain, through a heavy dose of satire, irony, and a not-so-subtle attempt at the scientific method, provides readers with an effective, but flawed, argument as to why humans are the lowest of animals in his essay The Damned Human Race. While the essay is successful in providing facts that support Twain's claim of humans have descended from animals, and not the other way around, his bias and pessimism towards the human race in general strongly emanates from the essay, and he does not provide any opportunity for the reader to gather any evidence to the contrary of his beliefs, further limiting the legitimacy of his argument.Twain provides several sound reasons for stating that humans are worse than animals, all conveyed in an effective manner. He makes simple and definitive statements which are generally believed to be true of humans and not animals, and elaborates on these statements to pinpoint just what is wrong with human beings. For example, Twain states â€Å"Man is the onl y Patriot† (Twain). While most believe this to be a positive trait of humans, Twain immediately follows this statement by stating that humans are the only species to kill one another for their countries, writing: Man is the only Patriot.He sets himself apart in his own country, under his own flag, and sneers at the other nations, and keeps multitudinous uniformed assassins on hand at heavy expense to grab slices of other people’s countries, and keep them from grabbing slices of his. And in the intervals between campaigns he washes the blood off his hands and works for the universal brotherhood of man, with his mouth.(Twain) Twain goes to on to point out that humans are the only species that take slaves, are the only species to take more than they need, and the only species that claim religions, and provides specific examples of different types of animals behaving differently in this regard (Twain). His points are effective arguments because he uses facts and strong lang uage to solidify each point that he makes, and does so in a way that leaves little for argument.While the points that Mark Twain makes in his essay are for all intents and purposes true, and he conveys his beliefs in a very effective manner, the essay as a whole is not a successful argument, largely because he primarily uses only one of the three main means of persuasion. Twain provides facts throughout his essay that are generally hard to argue with in regards to the bad things that humans are capable of that animals are not, but does not use emotion to trigger a response from the reader.This could be by design because of his use of heavy satire, and the fact that this was written in a scientific manner rather, which generally are written to not contain the author's emotions. There is a clear lack of ethical appeal, or ethos, in Twain's essay because of the fact that he is writing this in an official scientific capacity, though he is clearly not a scientist. He also does not provid e information that may contradict his beliefs, which prohibits the reader from gathering opposing views of the story.Twain could have easily provided facts and arguments that point out the good things that human beings are capable of that animals are not, such as charities, social welfare programs, and medical care. With that said, The Damned Human Race is an essay containing heavy satire, something that Twain makes apparent almost immediately by stating â€Å"I have not guessed or speculated or conjectured, but have used what is commonly called the scientific method† (Twain).By the time that this essay was published in 1905, Twain was an established as a well-known author, known for his humor and famous works rather than scientific prowess. Also, at this point in his life, Twain was also very open about his overall disdain for the human race in general, perhaps due to circumstances regarding his family and life experiences, though it has been debated that Twain had no more o f a troubled life than most normal people (Byrne 19).All of these things prohibit his essay from being considered a legitimate argument, and points to it being more a rant by the author, however effective it may be. While Mark Twain provides many solid facts about the human race that are true and should be noted by the reader, the heavy doses of clear bias and satire overwhelm any legitimacy the essay could possibly carry. It is also difficult to ignore the cynicism throughout the piece, even in the last line when Twain is describing the human races declension from animals, stating, â€Å"Below us, nothing† (Twain).

Friday, August 30, 2019

Philiosophies in Early Childhood Teaching Essay

Formal Writing Assignment: Introduction to Early Childhood Education Instructor: Ecole Morris- University of Montana-Western Goal: to develop a personal teaching philosophy of early childhood education based on research and analysis. Purpose: If someone asked you to explain your philosophy of teaching young children, what would you say? How would you begin to formulate a statement that captures the essence of your belief about teaching and learning? Teacher candidates are increasingly being asked to articulate their philosophy of teaching. This request is often in conjunction with the submission of a teaching portfolio for seeking teaching positions or dossier for promotion and tenure. A teaching philosophy is a statement of reflection about what you will do as a teacher. Your beliefs influence your action. It has been recognized by many teachers that the process of identifying a personal teaching philosophy and continuously examining, testifying, and verifying this philosophy can lead to change of teaching behaviors and ultimately enhance professional and personal growth. Assignment: For this assignment articulate your teaching philosophy in two phases. (100 points) 1. Introduction: at the beginning of the semester, you are required to write a 4-5 page paper. In it, consider the following points: * Why do you want to become an early childhood education teacher? * What type of teaching position do you hope to obtain, and why? * What are your strongest characteristics or talents as a potential early childhood educator? * What are the factors that influence your decision to pursue this career? 2. Areas to emphasize: Use the following questions to help you think about your beliefs regarding teaching young children. It is not necessary to respond to each of these questions in your written philosophy. You may also decide to comment on additional issues as well. Take some time to think about each one in some depth. * How do you view young children? What is the child’s role in his/her education? What do you belief about how young children learn? * What role does family play in your teaching? How will you include them in your classroom? * What are your views on inclusion, how will you include all children in your classroom? * How do you view the role of the teacher? How will your views influence your teaching? * What kind of environment do you hope to create in your future classroom? How does this relate to your basic beliefs about young children and learning? * What do you hope young children will become? What do you want them to achieve, accomplish, learn, feel, etc.? * What kind of feedback will you offer your students as they work? What kind of assessment will you use to be sure that students have met objectives? * Looking back at the history of early childhood education, who or what approaches have the greatest impression on you, and why? General Paper Format Suggestions: * Use present tense, in most cases. Write the paper in first-person (which is the most common and easiest for your audience to read). * Write in language and concepts that can be broadly appreciated. A general rule is that the statement should be written with the audience in mind. It may help to consider a school administrator (e.g. , school principal) as your audience. * Write a paper that will let your audience know where you stand in regard to important educational theories and practices. By including specific examples of teaching theories and approaches, you are able to let your reader take a mental â€Å"peek† of your classroom. * Make the paper memorable and unique. Think of this teaching philosophy as part of a job application where your readers are seeing many of these statements. What is going to set you apart from others? What about you are they going to remember? Create a vivid portrait of yourself as someone who is intentional about teaching and committed to his/her career. * A working draft will be developed and reviewed by a peer during the class. This working draft will be submitted with the final draft. * The personal philosophy paper must be typed, double-spaced, following APA (6th ed. ) guidelines. It must be a minimum of 4 pages not including references or appendices. A minimum of 3 references must be used. No more than 1 of these can be electronic (internet) references. A textbook bibliography can be a goldmine of references to follow up on as well.

Thursday, August 29, 2019

Managing communication knowledge and information Essay

London’s Heathrow is one of the world’s busiest airports. It is used by over 82 airlines flying to 180 destinations (in 85 countries) worldwide. The airport has five passenger terminals and a cargo terminal. In the 1950s, Heathrow had six runways, now it has just two parallel runways running eastwest of the airport. Heathrow has witnessed strong growth over recent decades, currently handling about 72.3 million passengers and over 477,000 flights a year compared to around 48 million passengers and 427,000 flights a year in 1996. In the absence of any increase in runway capacity, this growth has resulted in Heathrow’s runways operating at around 98% capacity compared to its main European competitors which operate at around 75% capacity, leading to increased delays, lower resilience and fewer destinations served. As the UK continues to face the challenge of airport capacity, Heathrow is considered the most deliverable solution – because it builds on one of the UK’s strongest national assets. Over the last decade since 2003,  £11bn has been spent on making Heathrow world-class, with the award-winning Terminal 5 and the new Terminal 2 (The Queen’s Terminal which opened in June 2014). There are other several reasons why Heathrow is best placed to deliver more jobs, more exports, business opportunities and air travel options for passengers. For example, the centre of economic gravity is to the west of London. There are 120 of the UK’s top 300 company HQs located within a 15 mile radius of Heathrow, compared to just 16 within 15 miles of Gatwick. Several businesses are located closer to Heathrow as they recognise the greater long-haul connections and surface access it has – making it easier for them to do business around the globe. The Thames Valley area, for example, has 60% more international businesses than the national UK average, 100% more US businesses and 260% more Japanese businesses. Heathrow will  help more UK businesses go global with a third runway as it already carries more freight exports and imports than every other UK airport combined, and cargo facilities will be doubled as a result of this plan. However, Heathrow authorities have faced a big problem, whether to build a new airport (option 1) or to increase the capacity of the existing one by building the 3rd runway and a sixth terminal (option 2). The second option needs less investment and is potentially easier to accomplish, but needs more political and social support and agreements as there are many stakeholders with different views about the proposal of a 3rd runway. On one side there are economic benefits, on the other side are considerations involving the environmental impact, increasing noise level and discontent of the people, particularly those living on the area close to the airport. The Airports Commission has been tasked with recommending the best way forward on the UK airport capacity issue. (Adapted from www.heathrowairport.com/about-us/, 2014) You have been recruited as a consultant to provide some contributions to the members of the Airports Commission, who have been tasked to produce a detailed report with recommendations that will help the Heathrow authorities in finding the best way forward on the 3rd runway plans to increase the airport capacity at Heathrow. Your communication skills, understanding of information needs and knowledge management will be crucial for you to be effective in this role. Note: This scenario is for Task 1 and Task 2 that cover Learning Outcomes LO1 and LO2. Dr Knowledge Mpofu September 2014 Semester Assignment Tasks Task 1: Assessing information and knowledge needs Based on Scenario for Task 1 and Task 2, you are expected to: AC1.1 Discuss  the range of decisions to be taken by the Heathrow Authorities and Management  Guidelines: Your answer should discuss the various possible decisions that can be taken by the Heathrow authorities in dealing with the issue highlighted in the scenario. AC1.2 Examine the information and knowledge needed to ensure effective decision taking based on the scenario Guidelines: In your answer to this question, you need to think about, and give examples of, the different types of information and knowledge needed by Heathrow authorities in order to ensure effective decision making in this case. The examples of types of information and knowledge you can give may be of different forms that include qualitative (descriptive information), quantitative (statistical data), official and unofficial information, policy and opinion, tacit and explicit knowledge. AC1.3 Assess internal and external sources of information and understanding based on the scenario Guidelines: Your answer should clearly identify the key sources of information that can help Heathrow authorities. These sources might include internal and external stakeholders of the company, formal and informal sources, team workers and customers. It will be useful to give examples in your answer. Task 2: Stakeholders, Personal networking and Decision-making process Based on Scenario for Task 1 and Task 2, you are expected to: AC2.1 Identify both internal and external key stakeholders of Heathrow airport who should be involved in the decision-making process in the issue highlighted in the scenario. AC2.2 Explain how Heathrow authorities can make contact with their internal and external stakeholders, and develop business relationships. AC2.3 Explain how Heathrow authorities can involve the identified stakeholders in the decision-making process, as appropriate. Guidelines: Your answer should explain the possible ways through which Heathrow authorities can connect, interact or share some ideas with some of the identified stakeholders of the organisation in order to develop business relationships with them. In addition, explain how these identified stakeholders can be involved in the decision-making process with a view to finding the best way forward on the 3rd runway plans to increase the airport capacity at Heathrow. AC2.4 In your role as a consultant in this case, design strategies for improving personal networking and involvement of stakeholders in the decision-making process based on the scenario and, (AC1.4) justify your recommendations for improvement. Guidelines: Your answer should suggest and describe possible ways (strategies) which you could use to improve your personal networking or connections with the identified stakeholders and involve them in discussions and decision-making processes based on the scenario. Any relevant approaches, illustrations or diagrams can be used in designing the strategies for improving networking and stakeholder participation in decision-making process (AC2.4), and your recommendations for improvement should be clearly justified to meet the assessment criteria AC1.4 as well. In this task, you will need to select and analyse the communication processes in an organisation which you are familiar with. In your selection of the organisation, make sure you will have access to both internal and external communication processes used by that organisation. Other students and lecturers will be interested to learn about the communication processes from your selected organisation. You are aware that you will need to find effective ways of communicating this to your colleagues and lecturers. In particular, you recognise that effective communication helps to improve relationships at work and other social situations by deepening your connections to stakeholders and improving teamwork, decision-making and problem solving for the success of an organisation. Based on Scenario for Task 3, you are expected to: AC3.1 Report on existing processes of communication that you have researched and observed in your selected organisation: (i) between management and employees (ii) between the organisation and its customers Guidelines: Your answer should clearly show evidence of some research carried out to identify the different information technology (IT) systems used within the organisation for communication purposes. The answer should also show how people within the organisation meet or create platforms for sharing ideas and decision-making. These opportunities for meetings could be structured and coordinated, planned, face-to-face, formal and informal. AC3.2 Design ways to improve the appropriateness of the communication processes (that you have identified in AC3.1 above). Guidelines: In designing the ways to improve the appropriateness of the communication processes, your answer may include some relevant illustrations or diagrams and specifying the IT systems involved in the process. AC3.3 Explain how the improvements to the ways and IT systems (that you have suggested above in AC3.2) can be implemented to ensure greater integration of systems of communication in the organisation. AC3.4 Based on Scenario for Task 3, create a personal plan to improve your own communication skills. A self-reflective summary is also be needed in this part of the task. Use the following guidelines to help you in preparing and creating an effective personal communication development plan: (i) Identify five communication skills relevant to your role These could be classified under verbal, non-verbal and written communication skills. (ii) Identify three strengths in your communication skills, and describe how each strength will enable you to be more effective or achieve in your role. (iii) Identify three weaknesses in your communication skills and describe how each weakness can be improved. (iv) Create your own Action Plan using a SMART Objective technique: Guidelines: Your Action plan should include the following: a. At least three SMART objectives that can be followed to improve your own personal communication skills b. Specific actions that can be taken to address each objective c. Possible barriers for each objective, and how you think the challenges can be addressed d. Resources and/or support required to achieve each objective e. Time scale: When you expect each objective to be achieved? (v) Produce a Self-Reflective Summary Guidelines: Finally, you are required to produce a Self-reflective summary on how you think the production of your Personal Communication Development Plan has helped you to understand your communication skills, and how to improve them. Your self-reflective summary may also include:   Information on how useful you found the techniques applied in this task (e.g Skills Audit table, SWOT analysis and Action plan based on SMART objectives). How helpful do you think the process of developing your Personal Communication Development Plan has been, and how this may be useful for you in the future. Task 3 covers assessment criteria AC3.1, AC3.2, AC3.3 and AC3.4 under LO3 Task 4: Improving Access to Systems of Information and Knowledge Scenario for Task 4: You are an Information Systems development specialist working for a Knowledge Management company in London. You have been hired by a University in London to produce information systems that could be used by registry and both students and lecturers in supporting their teaching and learning. In this role, you will produce technology systems which will specifically help the University to improve collection, formatting, storage and dissemination of information and knowledge, and assist in improving access to these resources for the benefit of the stakeholders of the university. Based on the Scenario for Task 4, you are expected to: AC4.1 Report on existing approaches to the collection, formatting, storage and dissemination of information and knowledge to support the teaching and learning at the University. Guidelines: Your answer should identify and explain how different information technology systems (IT) and other approaches which are used by the University particularly for collection, formatting, storage and dissemination of information and knowledge available to support their teaching and learning process. In your answer, you may also think about approaches that help to ensure the knowledge and information available within the University to their students is consistent, reliable, current, valid, legal and kept safely and confidential. AC4.2 Carry out appropriate changes to improve the collection, formatting, storage and dissemination of information and knowledge involving the teaching and learning at the University. Guidelines: Your answer should suggest possible changes that can be done to  improve the collection, formatting, storage and dissemination of information and knowledge at the University. You may think about better ways to handle knowledge and information, including how these could be displayed and disseminated to students, lecturers and other stakeholders within and outside the University while ensuring that the information is consistent, reliable, current, valid, legal and kept safely and confidential. AC4.3 Suggest one possible way (strategy) which you think can be used more effectively to improve access to information and knowledge for students, lecturers, management, employees and other stakeholders within and outside the University. Your answer should highlight some possible benefits of creating a way which can be used to increase access to information and knowledge that help in supporting the teaching and learning at the University.

Wednesday, August 28, 2019

Project Closure and Assessment Essay Example | Topics and Well Written Essays - 1000 words

Project Closure and Assessment - Essay Example In an argument by Bartlett (2004), basing a project on financial estimates is disregarding the elasticity of the corporate market. If a project greatly involves construction operations, the procurement process should be well managed and developed. In construction, quality matters. If the quality assurance is not provided, the project prospects will not be achieved. Apart from the procurement process, the staff at large should be well placed to support the whole project. If need be, organizations are advised to outsource high risk operations. Outsourcing increases the expertise employed in the project and it shares the risk involved in the whole project. The paper will focus on the Woody project and how well it was managed. It will provide an insight into the procurement process in the project. The startup was poorly managed in this project. In appropriately managed startups, organizations usually have effective production processes. After every project the startup usually determines whether or not the project was successful. Managers and owners have the obligation to inspect the results of the outcomes to determine whether or not it is according to the specified plan. In words by Bartlett (2004), managers and owners of organizations provide the first determination on whether or not the project was successful. However, this is usually not an assurance of success. If the production process fails to kick off as expected, the project is viewed as failure. In the case of Woody, the owners of the building did not inspect the manner in which the construction was conducted. After this, the setting off of the production process was very poor. Every single operation was behind schedule as the effects affected the company’s consumer base. It was poor management in that the owners of the company did not come up with any completion procedure after a period of years. There was no plan whatsoever that was formulated to foresee the transition from the old operation syst em to the new one. If the project were properly managed, there would be a procedure for inspection of the building by the owners, acceptance of the new building, testing of the new machines and the launching of the production process. The result of this poor management was harsh. The usual maintenance process carried out after every two weeks did not take place in time. Consumer deliveries were delayed by a period of two weeks. Several contractors also canceled the contracts citing insecurity and exposure to high levels of risk. The sale of finished goods also declined significantly. After the period of two years it was clearly evident that the project was poorly managed. The results seen at the startup after the completion of the project were diminishing. According to Wirick (2011), the success of a project is measured by its ability to comfortably upgrade the production process. In the Woody project this is not evident. To worsen the situation, its normal production process was ne gatively affected. Looking at Woody two years ago, the production process was much better. The procurement process in the Woody project was also tampered with. This can be translated to supply of goods of low quality. Kerzner (2010) argues that the supply of goods during a project is also a key to its success. In a proper managed project the procurement process is easily monitored and certified. In Woody’s case, the payment made to suppliers was not effectively consulted. Paying for services in consideration of

Tuesday, August 27, 2019

Hip hop Essay Example | Topics and Well Written Essays - 500 words

Hip hop - Essay Example Some of its political elements include mockery of the worst aspect of slavery such as the dozens (slave auctions) and battling (putting someone else down through poetry). In hip hop, African Americans found a medium to express their message, similar to the jazz music of the earlier decades to vent their frustrations against widespread racial discrimination and their marginalization in American society which only lately has been rectified by laws. In a sense, hip hop music and its accompanying culture is closely related to another and unique newly-invented black American form of expression which is slam poetry. Many people are not familiar with this new art form of spoken poetry but blacks were the first to popularize a more vibrant form of poetry reading, where it assumes the form of a performance act done on the stage and in full view of the public. Poets not only read out aloud their compositions but also act out their poems messages in a convincing and entertaining manner. Both hip hop and def poetry (as slam poetry is oftentimes alternatively called) share a common characteristic of free verse. It had a similar provenance from another black American musical art form which is reggae. Both forms of artistic expressions employ a rhythmic cadence that is pleasing to the ear and the mind; these forms exhibit creativity, originality and imaginative composition. In a sense, both are also considered as performance arts (Aptowics, 2008, 213) in which the singer or poet, as the case may be, has to dress for the part and employ a variety of props such as an appropriate dress, composure, tone of voice, manner of delivery, posture and non-verbal body language such as hand gestures or facial expressions. What I like most about hip hop and its culture is an ability to compose lyrics not constrained by meter, indentation or format; this is

Measures of Personality Research Assignment Essay

Measures of Personality Research Assignment - Essay Example e and practical rather than the abstract and theoretical, and finally Judgment-Perception (J-P) measuring someones preference for order and rules, rather than spontaneity and flexibility. All participants are tested through a series of questionnaires and their relative position on each of the four axes is mapped to get a complete 4-dimensional map of his or her personality. b. Circumstances under which the test is indicated : The test is used for predicting innate preferences for people for certain types of careers, and is used by recruitment agencies, the government and companies to assess the natural preferences for candidates or workers. In addition the test is widely used in education to assess the natural preferences and suitability of applicants for various courses, and in advising and counselling young people regarding a career choice. In addition, numerous people administer the test to themselves, to discover more about themselves, and it has been used in finding the right psychological type of partner by professional dating and matchmaking agencies. c. Reliability and validity : The MBTI has been studied by numerous researchers with regards to objectivity and validity, and most researchers have found that the eight preference poles correspond in practice to theory for most people. (Hammer, 1996). Tzengs (1984) factor analysis of 125 students confirmed the validity of the four axes based on the MBTI. d. Factors to be considered by user: Users often find that the test is more reliably scored when someone administers it rather than when they self-test it. In addition, the test indicators do not mean that users cannot progress in areas where the test has not shown them to have a natural preference – by training and trying hard, they can still progress. e. My own opinion of the usefulness. The test is essentially a psychological tool for assessing how people prefer things naturally. However its practical utility in the real world is severely limited as

Monday, August 26, 2019

British Imperialism in Africa Research Paper Example | Topics and Well Written Essays - 1000 words

British Imperialism in Africa - Research Paper Example Despite control over few regions of Africa, British imperialism had long lasting effects that contribute to bring change in various sectors of the African regions including social, economical, cultural, and political. In this paper, we shall discuss the role of British imperialism in Africa from 1870 to 1900 and its socio-cultural impact on African colonies. British Imperialism in Africa Historical records witness British Imperialism in Africa from 1870 to 1900 which resulted in division of Africa into seven major regions of Europe. It is found that many western powers intended to establish their rule in African regions; similarly, between 1870 and 1990, Great Britain showed efforts to consolidate its foothold on the African coast in order to expand their rule over the continent of Africa1. The British rule mainly focused on regions which open gate for profitable trade and marketing and contributed to further strengthen their economy. It is noteworthy that during 1869 to 1870 the Bri tish rule was focusing on profitable trade and market, but it stepped forward towards Africa which is not a financially strong region. Additionally, Africa had various conflicting issues within its state boundaries, but still the British Empire attempted to invade its major parts2. ... wed the British to take control over their West coast for palm oil because the native politicians were aware of the fact that they cannot avail their own natural resource without the British support4. Another reason behind expansion of England and interest of Britain in the African lands was its biggest money generator, India. In 1875, British intended to make their route towards India in order to do so it bought shares in Suez Canal of Egypt and after the battles of Tel el Kabir and the Nile, British gained entire control over Egypt, a major power of Africa5. Further in 1877, again British had fear of losing India thus they made a way by invading South Africa because Cape Town was an important route towards India6. In South Africa there were two threatening groups for the British Empire Bores and Zulus. In 1879, British power was defeated by Bores and after two decades they went for War with Zulus in 1899 because they badly wanted to save their route to India7. It has also been noti ced that gaining profit through trade was the major aim of the British Imperialism in Africa and addition of colonies can only bring more profit to them. Furthermore, British considered that African colonies would help them gain allies and aid them in winning economic war they had with Germany8. Moreover, in 1898 a war started between France and Britain over small colonies near Niger River and consequently Britain captured Khartoum. Until 1900, the British Imperialism got over many colonies of Africa and by the end of Imperialism Africa was divided into seven European regions. The division and strong influence of the British Imperialism in Africa had affected social and cultural aspects of the European communities9. Social and Cultural Impact on Africa British Imperialism left destructive

Sunday, August 25, 2019

Dell Supply Chain Research Paper Example | Topics and Well Written Essays - 1250 words

Dell Supply Chain - Research Paper Example Second is the strategic partnership: relationship with supplier, customer and distributors. The development of the communication channels for critical information (market demands, availability of supplies) and operational improvement (transportation issues and compliance of regional specifications for products). Sourcing contracts and other purchasing decisions, more sources of suppliers meaning more options in purchasing with more information flow. A wiser choice could be made in term of pricing and quality of suppliers. 3. Analyze two of the decisions you have to make (one strategic, one operational) using relevant frameworks or models. Explain the results of the analysis and their implications. (the most important part) 40%marks The key to Dell's success as World's No. 1 Computer System provider is due to its success in integration of both the process and people as in the Dells's Supply Chain DNA (figure below) (Fugate and Mentzer, 2004). The elements in this DNA model include internal collaboration (production), demand management (procurement), financial business fundamentals (sales and finance) and leverage partners (suppliers). These elements each by themselves is a complicated bodies and managing them successfully require a bed of knowledge. The question is, how does Dell take them all into a smoothly The answer is by strategically integrating them by Dell's DNA (Fugate and Mentzer, 2004) information technologies. To be really specific, Dell is utilizing software - i2 Supply Chain Management to plan the production and communicate with the suppliers (Atlman et al., 2004). "i2 streamlines the supply chain by providing component suppliers and Dell planners with global views of product demand and material requirements. It also provides real-time factory scheduling and inventory management, so employees can generate key reports based on accurate and timely data, pinpoint inventory on the factory floor, and receive supplier deliveries on a true just-in-time basis" (Altman et al., 2004) The sales, production and supply are linked together through this software. Thus, in the new company, similar software

Saturday, August 24, 2019

Response Assignment Example | Topics and Well Written Essays - 250 words - 18

Response - Assignment Example The student should clarify this. Moreover, the student does not identify any nonverbal communication. In a noisy environment, it is quite obvious that the two would have probably used several facial expressions or gestures. These are important aspects of the transactional model of communication. Student 2 was having a discussion with his friends at the San Francisco Aquarium. The two friends were discussing their previous experiences. Student 2’s friend responded using nonverbal communication when asked if they liked the beach in San Diego. Student 2 was keen to observe the facial expression and gestures of his friend. He noted the wink and thumb up which indicated that his friend liked the place. The success of the communication was based on the ability of student 2 to understand non-verbal communication. I agree with the idea that, the reaction from his friend indicated that he liked the place, and he would like to visit the place again. Their conversation was interrupted by the loud noise of the train. They could no longer communicate and had to get back to the aquarium. Noise interrupts the smoothness of a conversation and can stop conversations. However, the student should clarify if they attempted nonverbal communication during the noise. This is necessary in e xplaining the transactional model of

Friday, August 23, 2019

Marketing Audit Essay Example | Topics and Well Written Essays - 3250 words

Marketing Audit - Essay Example However, this was a great challenge to Nokia, specifically because new companies began to emerge, that were able to produce cheap mobile phones, which were also innovative. During the 21st century, Nokia began losing competition to mobile phone giants such as Apples, Samsung, and the numerous Chinese mobile companies that produced cheap, but innovative mobile phones (Sundback, 2008). One of the major reasons as to why Nokia was losing competition is based on the fact that it had a poor marketing strategy. Nokia was unable to effectively communicate its proposition, and what their products stand for. This is an aspect that Apples and Samsung have managed to communicate effectively in their marketing campaigns. Furthermore, the advertisements of Nokia are not consistent, communicating messages which are not relevant to their target market (Barnes, 2011). It is important to understand that to achieve success in marketing, it is essential for a business organization to highlight how their products serve the needs of their customers. On this note, failure of Nokia to achieve market growth is not because of low quality products, but mainly because of their poor marketing strategies. Nokia is a company in the telecommunication industry. In reviewing the marketing strategy of Nokia, there is a need of concentrating on the strategy that the organization employed in marketing its Nokia brand of mobile phones (Glotz, Bertschi and Locke, 2005). This report will provide a critique of the marketing strategy of the organization, identifying various weaknesses that the company needs to improve on. The main intention of providing a critique on the marketing strategy of Nokia is to make a recommendation on how to improve its marketing mix, in order to be an effective competitor in the telecommunications industry (Häikiö, 2002). On this basis, this report is a critical analysis of the marketing strategy of Nokia

Thursday, August 22, 2019

Religious and Ethnic Groups Essay Example for Free

Religious and Ethnic Groups Essay Buddhism is a religious group as depicted from the world’s history that began in the 6th century BCE, in today’s Northern India. Buddhism was founded by a wealthy man of Indian dysentery called Siddhartha Gautama. Siddhartha Gautama’s main concern was to teach people how to realize great spiritual development. These teachings focus on areas like tradition/customs, beliefs, ethics, meditation and philosophy and making people more enlightened; Buddha means ‘to awaken’. To the religious group boast of a huge following of about 300million across the world including 0. 7 percent of U. S. A’s religious composition based on U. S’s Census Bureau Document (Seager, 2012). Buddhism is a religious group that differs broadly from other groups in America. The difference is eminent in the way they carry out various practice. Some examples are worship, beliefs, culture, doctrines, and in other routine practices. Buddhism, unlike other religious groups, believes in the existence of only one Supreme Being ‘God’. In contrast to most groups, Buddhism spirituality is of personal discipline rather than faith in ‘God’. A lot of differences may be present when attempting to draw a comparison between Buddhism and the other religious groups in America. Buddhists Experience in America Buddhism has received its fair deal of mixed reception from other religious avenue. Some people have good perception and understand their teachings seek to uphold good morals and values. Buddhism also seeks a harmonious co-existence with other people in society even if they are not practicing the same religion. Others have perceived them as having a bizarre view deeming its operation as being mysterious. Buddhism is unique in conducting their routine religious practices and beliefs. Some religious groups have upheld Buddhism, not as a religion but merely a philosophy (Seager, 2012). They have even incorporated some practices like meditation as an art of realization physical and emotional well being as yoga in pursuit of reliving off stress. They have also sorted in some Buddhism cultural element and used them to perfect their own religions. Contribution and Discrimination of Buddhism Historically in American culture Buddhism has contributed adversely in development of America’s culture. Many Buddhists doctrine and daily routine practices are borrowed and used to blend America’s culture. Example of such practice teachings of how people perceive life and attitude, changed Buddhism has mentored Great America’s scientists and philosophers (Seager, 2012). They borrow ideas from Buddhism teachings. Some of the ways in which Buddhism is practiced in America include stress reduction treatment. In addition, famous movies and songs based on Buddhism, such as Seven Years in Tibet, Little Buddha, The Matrix, and Star Wars, has helped the advertisement industry. Another instance is the Master Card commercial that shows an image of Woman Meditating. There is an increasing number of Americans who visit the Buddhist temples and also practice meditation in privacy. Buddhist Fellowship organization is a very large group that promotes peace, environmental advocacy, and conducts homeless and prison outreach. Buddhism has experienced discrimination minimally compared to other religious groups. Discrimination happens within its own religion and culture primarily against Buddhist women. All Buddhist women are ordained to follow laws and disciplines such as bhikkhunis. However, Buddhist nuns have come together to fight for their rights. The source of this prejudice was because the Buddhist nuns have increased in number and they want to eliminate them from the religion. Buddhism has helped me learn about meditation which can be used in reducing stress and as a way of relaxing. Asian Ethnic Group The Asian American comprises of a 5% of the American population (Espiritu, 2011). In the recent years, the Asian ethnic group is considered among the fastest growing group in America. The Americans refer to subgroups such as the Chinese, Filipino, Indians, Koreans, Japanese and Vietnamese. Most Asian Americans were born in America while others have been the immigrants who have settled in America. Asian differs from the other ethnic groups because from history Asians have continued to follow their religions, unlike many other groups. The Asian Americans are known for their diligence, strong family values and their respect for education, authority, and discipline unlike any other ethnic group in America. Asian American Contribution and Discrimination The Asian American has contributed greatly in the formation of American society. These contributions include constructions of railway, joining the military and protecting the Americans. Asians have also contributed in creating internet sites such as youtube and yahoo. The Asians have influenced other areas like fashion, religion, science and culture. For instance, the kung fu culture of the Chinese is greatly employed in Hollywood while creating action movies. Acts of discrimination towards Asian Americans in America are similar to other minority group. This racial discrimination bars the Asian American from participating in politics (Espiritu, 2011). The reason Asian Americans are discriminated against is Americans consider them foreigners. In conclusion, Buddhism is an Asian practice which the Asian have practiced almost all their lives, but this practice came to be known only in recent years. Discrimination of Asian Americans means that their religion, cultures, and practices are discriminated against. Buddhism is different from Asian Ethnic group because Buddhism is a practice done by the Asian communities. Discrimination should never be practiced in America because America is a multicultural society and the majority of people in America are citizens by birth. References Espiritu, Y. L. (2011). Asian American pan ethnicity: Bridging institutions and identities. Philadelphia: Temple University Press. Seager, R. H. (2012). Buddhism in America. New York: Columbia University Press.

Wednesday, August 21, 2019

What Should Altiuss Objectives Be What Essay Example for Free

What Should Altiuss Objectives Be What Essay What should Altius’s objectives be? What trade- off’s must it manage? With Altius staying just focussing with the manufacturing top of the line golf balls, their business would only continue to drop. Fortunately the brand value of Altuis was recognised and respected very much by many top notch golfers of the country, but this does not mean that they had a lot of profits. Focusing on the low price golf equipments, such as Elevate golf ball and changing the marketing strategy from targeting proficient golf equipments to low cost golf equipments and more fun oriented golf equipment for new golf players will enhance the profitability of Altius. This is because golf industry is vitalizing by the efforts of USGA, through the encouragement of new golf players to play golf with relaxed rules. Therefore, it is a good time to mark new players through widespread marketing of low cost and non-confirming golf balls, which enables new golf players to hit the ball perfectly. The new golf ball â€Å"Elevate† being sold below the 40% of its premium Victor TX brand, enables Altius Golf to capture a new generation of golf players. Other competitors were becoming very competitive; they were providing the best service to elite players and also were reaching the casual players with cheaper products, hence reaching more golfers than Altius. Maintaining the current strategy will make Atius obsolete pretty soon. In a business, trade off’s are quite common. You tend to be having a core competency at one aspect but not all, this does not mean you stick to the former. Hence Altius must enter the not so costly markets. This might mean that the 70% profits have to reduce by at least 10% and utilised in trade offs. This 10 % has to be used to reach the broader recreational market. Altius can very well get back to producing and being the producer of top quality balls. But on the long run they should create an impression which made them look concerned for the game as well as increasing, motivating players. Altius Golf’s balls are expensive as compared to competitor’s golf balls and new golf players are not willing to spend more on expensive golf equipments. Also there could be a possibility of creating a group for searching lost balls which were costlier when sold , repairing them and selling them as a low cost but high quality balls for the casual golfers. They could market this by bringing up the environmental aspects involved while using the materials used for making  the balls. Altius Golf’s competitors are moving with the industry trends and are trying to offer balls and other golf equipments which are easy to use and helps new golf users to hit the shot as they require, while Altius Golf is still offering equipments which are for professionals, although golf professionals value the equipments of Altius but the industry trend shows that recent recession period has decreased the number of professional golf players and new golf players are being encouraged to play golf.

Tuesday, August 20, 2019

Factors Affecting Web Applications Maintenance

Factors Affecting Web Applications Maintenance Chapter 1 1.1 Introduction Software engineering [PRE01] is the process associated with industrial quality software development, the methods used to analyze, design test computer Software, the management techniques associated with the control monitoring of Software projects the tools used to support process, methods, techniques. In Software Development Life Cycle, the focus is on the activities like feasibility study, requirement analysis, design, coding, testing, maintenance. Feasibility study involves the issues like technical/economical/ behavioral feasibility of project. Requirement analysis [DAV93] emphasizes on identifying the needs of the system producing the Software Requirements Specification document (SRS), [JAL04] that describes all data, functional behavioral requirements, constraints, validation requirements for Software. Software Design is to plan a solution of the problem specified by the SRS document, a step in moving from the problem domain to the solution domain. The output of this phase is the design document. Coding is to translate the design of the system into code in a programming language. Testing is the process to detect defects minimize the risk associated with the residual defects. The activities carried out after the delivery of the software comprises the maintenance phase. 1.2 Evolution of Software Testing Discipline The effective functioning of modern systems depends on our ability to produce software in a cost-effective way. The term software engineering was first used at a 1968 NATO workshop in West Germany. It focused on the growing software crisis. Thus we see that the software crisis on quality, reliability, high costs etc. started way back when most of todays software testers were not even born. The attitude towards Software Testing [BEI90] underwent a major positive change in the recent years. In the 1950s when Machine languages were used, testing was nothing but debugging. When in the 1960s, compilers were developed, testing started to be considered a separate activity from debugging. In the 1970s when the software engineering concepts were introduced, software testing began to evolve as a technical discipline. Over the last two decades there has been an increased focus on better, faster and cost-effective software. Also there has been a growing interest in software safety, protection and security and hence an increased acceptance of testing as a technical discipline and also a career choice. Now to answer, What is Testing? we can go by the famous definition of Myers [MYE79], which says, Testing is the process of executing a program with the intent of finding errors. According to Humphrey, software testing is defined as, the execution of a program to find its faults. Testing is the process to prove that the software works correctly [PRA06]. Software testing is a crucial aspect of the software life cycle. In some form or the other it is present at each phase of (any) software development or maintenance model. The importance of software testing and its impact on software cannot be underestimated. Software testing is a fundamental component of software quality assurance and represents a review of specification, design and coding. The greater visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing. It is not uncommon for a software organization to spend 40-50% of its effort on testing. During testing, the software engineering produces a series of test cases that are used to rip apart the software they have produced. Testing is the one step in the software process that can be seen by the developer as destructive instead of constructive. Software engineers are typically constructive people and testing requires them to overcome preconceived concepts of correctness and deal with conflicts when errors are identified. A successful test is one that finds a defect. This sounds simple enough, but there is much to consider when we want to do software testing. Besides finding faults, we may also be interested in testing performance, safety, fault-tolerance or security. Testing often becomes a question of economics. For projects of a large size, more testing will usually reveal more bugs. The question then becomes when to stop testing, and what is an acceptable level of bugs. This is the question of good enough software. Testing is the process of verifying that a product meets all requirements. A test is never complete. When testing software the goal should never be a product completely free from defects, because its impossible. According to Peter Nielsen, The average is 16 faults per 1000 lines of code when the programmer has tested his code and it is believed to be correct. When looking at a larger project, there are millions of lines of code, which makes it impossible to find all present faults. Far too often products are released on the market with poor quality. Errors are often uncovered by users, and in that stage the cost of removing errors is large in amount. 1.3 Objectives of Testing Glen Myers [MYE79] states a number of rules that can serve well as testing objectives: Testing is a process of executing a program with the intent of finding an error. A good test is one that has a high probability of finding an as yet undiscovered error. A successful test is one that uncovers an as yet undiscovered error. The objective is to design tests that systematically uncover different classes of errors do so with a minimum amount of time effort. Secondary benefits include Demonstrate that Software functions appear to be working according to specification. That performance requirements appear to have been met. Data collected during testing provides a good indication of Software reliability some indication of Software quality. Testing cannot show the absence of defects, it can only show that Software defects are present. 1.4 Software Testing Its Relation with Software Life Cycle Software testing should be thought of as an integral part of the Software process an activity that must be carried out throughout the life cycle. Each phase in the Software lifecycle has a clearly different end product such as the Software requirements specification (SRS) documentation, program unit design program unit code. Each end product can be checked for conformance with a previous phase against the original requirements. Thus, errors can be detected at each phase of development. Validation Verification should occur throughout the Software lifecycle. Verification is the process of evaluating each phase end product to ensure consistency with the end product of the previous phase. Validation is the process of testing Software, or a specification, to ensure that it matches user requirements. Software testing is that part of validation verification associated with evaluating analysing program code. It is one of the two most expensive stages within the Software lifecycle, the other being maintenance. Software testing of a product begins after the development of the program units continues until the product is obsolete. Testing fixing can be done at any stage in the life cycle. However, the cost of finding fixing errors increases dramatically as development progresses. Changing a Requirements document during the first review is inexpensive. It costs more when requirements change after the code has been written: the code must be rewritten. Bug fixes are much cheaper when programmers find their own errors. Fixing an error before releasing a program is much cheaper than sending new disks, or even a technician to each customers site to fix it later. It is illustrated in Figure 1.1. The types of testing required during several phases of Software lifecycle are described below: Requirements Requirements must be reviewed with the client; rapid prototyping can refine requirements accommodate changing requirements. Specification The specifications document must be checked for feasibility, traceability, completeness, absence of contradictions ambiguities. Specification reviews (walkthroughs or inspections) are especially effective. Design Design reviews are similar to specification reviews, but more technical. The design must be checked for logic faults, interface faults, lack of exception handling, non-conformance to specifications. Implementation Code modules are informally tested by the programmer while they are being implemented (desk checking). Thereafter, formal testing of modules is done methodically by a testing team. This formal testing can include non-execution-based methods (code inspections walkthroughs) execution-based methods (black-box testing, white-box testing). Integration Integration testing is performed to ensure that the modules combine together correctly to achieve a product that meets its specifications. Particular care must be given to the interfaces between modules. The appropriate order of combination must be determined as top-down, bottom-up, or a combination thereof. Product Testing The functionality of the product as a whole is checked against its specifications. Test cases are derived directly from the specifications document. The product is also tested for robustness (error-handling capabilities stress tests). All source code documentation are checked for completeness consistency. Acceptance Testing The Software is delivered to the client, who tests the Software on the actual h/w, using actual data instead of test data. A product cannot be considered to satisfy its specifications until it has passed an acceptance test. Commercial off-the-shelf (or shrink-wrapped) Software usually undergoes alpha beta testing as a form of acceptance test. Maintenance Modified versions of the original product must be tested to ensure that changes have been correctly implemented. Also, the product must be tested against previous test cases to ensure that no inadvertent changes have been introduced. This latter consideration is termed regression testing. Software Process Management The Software process management plan must undergo scrutiny. It is especially important that cost duration estimates be checked thoroughly. If left unchecked, errors can propagate through the development lifecycle amplify in number cost. The cost of detecting fixing an error is well documented is known to be more costly as the system develops. An error found during the operation phase is the most costly to fix. 1.5 Principles of Software Testing Software testing is an extremely creative intellectually challenging task. The following are some important principles [DAV95] that should be kept in mind while carrying Software testing [PRE01] [SUM02]: Testing should be based on user requirements: This is in order to uncover any defects that might cause the program or system to fail to meet the clients requirements. Testing time resources are limited: Avoid redundant tests. It is impossible to test everything: Exhaustive tests of all possible scenarios are impossible, because of the many different variables affecting the system the number of paths a program flow might take. Use effective resources to test: This represents use of the most suitable tools, procedures individuals to conduct the tests. Only those tools should be used by the test team that they are confident familiar with. Testing procedures should be clearly defined. Testing personnel may be a technical group of people independent of the developers. Test planning should be done early: This is because test planning can begin independently of coding as soon as the client requirements are set. Test for invalid unexpected input conditions as well as valid conditions: The program should generate correct messages when an invalid test is encountered should generate correct results when the test is valid. The probability of the existence of more errors in a module or group of modules is directly proportional to the number of errors already found. Testing should begin at the module: The focus of testing should be concentrated on the smallest programming units first then expand to other parts of the system. Testing must be done by an independent party: Testing should not be performed by the person or team that developed the Software since they tend to defend the correctness of the program. Assign best personnel to the task: Because testing requires high creativity responsibility only the best personnel must be assigned to design, implement, analyze test cases, test data test results. Testing should not be planned under the implicit assumption that no errors will be found. Testing is the process of executing Software with the intention of finding errors. Keep Software static during test: The program must not be modified during the implementation of the set of designed test cases. Document test cases test results. Provide expected test results if possible: A necessary part of test documentation is the specification of expected results, even though it is impractical. 1.6 Software Testability Its Characteristics Testability is the ability of Software (or program) with which it can easily be tested [PRE01] [SUM02]. The following are some key characteristics of testability: The better it works, the more efficient is testing process. What you see is what you test (WYSIWYT). The better it is controlled, the more we can automate or optimize the testing process. By controlling the scope of testing we can isolate problems perform smarter retesting. The less there is to test, the more quickly we can test it. The fewer the changes, the fewer the disruptions to testing. The more information we have, the smarter we will test. 1.7 Stages in Software Testing Process Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-systems, which are built out of modules that are composed of procedures functions. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation. The most widely used testing process consists of five stages that are illustrated in Table 1.1. Errors in program components, say may come to light at a later stage of the testing process. The process is therefore an iterative one with information being fed back from later stages to earlier parts of the process. The iterative testing process is illustrated in Figure 1.2 and described below: Unit Testing: Unit testing is code-oriented testing. Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components. Module Testing: A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures functions. A module encapsulates related components so it can be tested without other system modules. Sub-system (Integration) Testing: This phase involves testing collections of modules, which have been integrated into sub-systems. It is a design-oriented testing is also known as integration testing. Sub-systems may be independently designed implemented. The most common problems, which arise in large Software systems, are sub-systems interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by rigorously exercising these interfaces. System Testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors that result from unanticipated interactions between sub-systems system components. It is also concerned with validating that the system meets its functional non-functional requirements. Acceptance Testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data. Acceptance testing may reveal errors omissions in the systems requirements definition (user-oriented) because real data exercises the system in different ways from the test data. Acceptance testing may also reveal requirement problems where the system facilities do not really meet the users needs (functional) or the system performance (non-functional) is unacceptable. 1.8 The V-model of Testing To test an entire software system, tests on different levels are performed. The V model [FEW99], shown in figure 1.3, illustrates the hierarchy of tests usually performed in software development projects. The left part of the V represents the documentation of an application, which are the Requirement specification, the Functional specification, System design, the Unit design. Code is written to fulfill the requirements in these specifications, as illustrated in the bottom of the V. The right part of the V represents the test activities that are performed during development to ensure that an application corresponding to its requirements. Unit tests are used to test that all functions and methods in a module are working as intended. When the modules have been tested, they are combined and integration tests are used to test that they work together as a group. The unit- and integration test complement the system test. System testing is done on a complete system to validate that it corresponds to the system specification. A system test includes checking if all functional and all non-functional requirements have been met. Unit, integration and system tests are developer focused, while acceptance tests are customer focused. Acceptance testing checks that the system contains the functionality requested by the customer, in the Requirement specification. Customers are usually responsible for the acceptance tests since they are the only persons qualified to make the judgment of approval. The purpose of the acceptance tests is that after they are preformed, the customer knows which parts of the Requirement specification the system satisfies. 1.9 The Testing Techniques To perform these types of testing, there are three widely used testing techniques. The above said testing types are performed based on the following testing techniques: Black-Box testing technique Black box testing (Figure 1.4) is concerned only with testing the specification. It cannot guarantee that the complete specification has been implemented. Thus black box testing is testing against the specification and will discover faultsofomission, indicating that part of the specification has not been fulfilled. It is used for testing based solely on analysis of requirements (specification, user documentation). In Black box testing, test cases are designed using only the functional specification of the software i.e without any knowledge of the internal structure of the software. For this reason, black-box testing is also known as functional testing. Black box tests are performed to assess how well a program meets its requirements, looking for missing or incorrect functionality. Functional testing typically exercise code with valid or nearly valid input for which the expected output is known. This includes concepts such as boundary values. Performance tests evaluate response time, memory usage, throughput, device utilization, and execution time. Stress tests push the system to or beyond its specified limits to evaluate its robustness and error handling capabilities. Reliability tests monitor system response to represent user input, counting failures over time to measure or certify reliability. Black box Testing refers to analyzing a running program by probing it with various inputs. This kind of testing requires only a running program and does not make use of source code testing of any kind. In the security paradigm, malicious input can be supplied to the program in an effort to cause it to break. If the program breaks during a particular test, then a security problem may have been discovered. Black box testing is possible even without access to binary code. That is, a program can be tested remotely over a network. All that is required is a program running somewhere that is accepting input. If the tester can supply input that the program consumes (and can observe the effect of the test), then black box testing is possible. This is one reason that real attackers often resort to black box techniques. Black box testing is not an alternative to white box techniques. It is a complementary approach that is likely to uncover a different type of errors that the white box approaches. Black box testing tries to find errors in the following categories: Incorrect or missing functions Interface errors Errors in data structures or external database access Performance errors, and Initialization and termination errors. By applying black box approaches we produce a set of test cases that fulfill requirements: Test cases that reduce the number of test cases to achieve reasonable testing Test cases that tell us something about the presence or absence of classes of errors. The methodologies used for black box testing have been discussed below: 1.9.1.1 Equivalent Partitioning Equivalence partitioning is a black box testing approach that splits the input domain of a program into classes of data from which test cases can be produced. An ideal test case uncovers a class of errors that may otherwise before the error is detected. Equivalence partitioning tries to outline a test case that identifies classes of errors. Test case design for equivalent partitioning is founded on an evaluation of equivalence classes for an input condition [BEI95]. An equivalence class depicts a set of valid or invalid states for the input condition. Equivalence classes can be defined based on the following [PRE01]: If an input condition specifies a range, one valid and two invalid equivalence classes are defined. If an input condition needs a specific value, one valid and two invalid equivalence classes are defined. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined. If an input condition is Boolean, one valid and invalid class is outlined. 1.9.1.2 Boundary Value Analysis A great many errors happen at the boundaries of the input domain and for this reason boundary value analysis was developed. Boundary value analysis is test case design approach that complements equivalence partitioning. BVA produces test cases from the output domain also [MYE79]. Guidelines for BVA are close to those for equivalence partitioning [PRE01]: If an input condition specifies a range bounded by values a and b, test cases should be produced with values a and b, just above and just below a and b, respectively. If an input condition specifies various values, test cases should be produced to exercise the minimum and maximum numbers. Apply guidelines above to output conditions. If internal program data structures have prescribed boundaries, produce test cases to exercise that data structure at its boundary. White-Box testing technique White box testing (Figure 1.5) is testing against the implementation as it is based on analysis of internal logic (design, code etc.) and will discover faultsofcommission, indicating that part of the implementation is faulty. Designing white-box test cases requires thorough knowledge of the internal structure of software, and therefore the white-box testing is also called the structural testing. White box testing is performed to reveal problems with the internal structure of a program. A common goal of white-box testing is to ensure a test case exercises every path through a program. A fundamental strength that all white box testing strategies share is that the entire software implementation is taken into account during testing, which facilitates error detection even when the software specification is vague or incomplete. The effectiveness or thoroughness of white-box testing is commonly expressed in terms of test or code coverage metrics, which measure the fraction of code exercised by test cases. White box Testing involves analyzing and understanding source code. Sometimes only binary code is available, but if you decompile a binary to get source code and then study the code, this can be considered a kind of white box testing as well. White box testing is typically very effective in finding programming errors and implementation errors in software. In some cases this activity amounts to pattern matching and can even be automated with a static analyzer. White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that: Guarantee that all independent paths in a module have been exercised at least once Exercise all logical decisions Execute all loops at their boundaries and in their operational bounds Exercise internal data structures to maintain their validity. There are several methodologies used for white box testing. We discuss some important ones below. 1.9.2.1 Statement Coverage The statement coverage methodology aims to design test cases so as to force the executions of every statement in a program at least once. The principal idea governing the statement coverage methodology is that unless a statement is executed, we have way of determining if an error existed in that statement. In other words, the statement coverage criterion [RAP85] is based on the observation that an error existing in one part of a program cannot be discovered if the part of the program containing the error and generating the failure is not executed. However, executed a statement once and that too for just one input value and observing that it behaves properly for that input value is no guarantee that it will behave correctly for all inputs. 1.9.2.2 Branch Coverage In branch coverage testing, test cases are designed such that the different branch conditions are given true and false values in turn. It is obvious that branch testing guarantees statement coverage and thus is a stronger testing criterion than the statement coverage testing [RAP85]. 1.9.2.3 Path Coverage The path coverage based testing strategy requires designing test cases such that all linearly independents paths in the program are executed at least once. A linearly independent path is defined in terms of the control flow graph (CFG) of the program. 1.9.2.4 Loop testing Loops are very important constructs for generally all the algorithms. Loop testing is a white box testing technique. It focuses exclusively on the validity of loop constructs. Simple loop, concatenated loop, nested loop, and unstructured loop are four different types of loops [BEI90] as shown in figure 1.6. Simple Loop: The following set of tests should be applied to simple loop where n is the maximum number of allowable passes thru the loop: Skip the loop entirely. Only one pass thru the loop. Two passes thru the loop. M passes thru the loop where m N-1, n, n+1 passes thru the loop. Nested Loop: Beizer [BEI90] approach to the nested loop Start at the innermost loop. Set all other loops to minimum value. Conduct the simple loop test for the innermost loop while holding the outer loops at their minimum iteration parameter value. Work outward, conducting tests for next loop, but keeping all other outer loops at minimum values and other nested loops to typical values. Continue until all loops have been tested. Concatenated loops: These can be tested using the approach of simple loops if each loop is independent of other. However, if the loop counter of loop 1 is used as the initial value for loop 2 then approach of nested loop is to be used. Unstructured loop: This class of loops should be redesigned to reflect the use of the structured programming constructs. 1.9.2.5 McCabes Cyclomatic Complexity The McCabes Cyclomatic Complexity [MCC76] of a program defines the number of independent paths in a program. Given a control flow Graph G of a program, the McCabes Cyclomatic Complexity V(G) can be computed as: V(G)=E-N+2 Where E is the number of edges in the control flow graph and N is the number of nodes of the control flow graph. The cyclomatic complexity value of a program defines the number of independent paths in the basis set of the program and provides a lower bound for the number of test cases that must be conducted to ensure that all statements have been executed at least once. Knowing the number of test cases required does not make it easy to derive the test cases, it only gives an indication of the minimum number of test cases required. The following is the sequences of steps that need to be undertaken for deriving the path coverage based test case of a program. Draw the CFG. Calculate Cyclomatic Complexity V(G). Calculate the basis set of linearly independent paths. Prepare a test case that will force execution of each path in the basis set. 1.9.2.6 Data Flow based Testing The data flow testing method chooses test paths of a program based on the locations of definitions and uses of variables in the program. Various data flow testing approaches have been examined [FRA88] [NTA88] [FRA93]. For data flow testing each statement in program is allocated a unique statement number and that each function does not alter its parameters or global variables. For a statement with S as its statement number, DEF(S) = {X| statement S contains a definition of X} USE(S) = {X| statement S contains a use of X} If statement S is if or loop statement, its DEF set is left empty and its USE set is founded on the condition of statement S. The definition of a variable X at statement S is live at statement S, if there exists a path from statement S to S which does not contain any condition of X. A definition-use chain (or DU chain) of variable X is of the type [X,S,S] where S and S are statement numbers, X is in DEF(S), USE(S), and the definition of X in statement S is live at statement S. One basic data flow testing strategy is that each DU chain be covered at least once. Data flow testing strategies are helpful for choosing test paths of a program including nested if and loop statements 1.9.3 Grey-Box testing technique Grey box testing [BIN99] designs test cases using both responsibility-based (black box) and implementation-based (white box) approaches. To completely test a web application one needs to combine the two approaches, White-box and Black-box testing. It is used for testing of Web based applications. The Gray-box testing approach takes into account all components ma Factors Affecting Web Applications Maintenance Factors Affecting Web Applications Maintenance Chapter 1 1.1 Introduction Software engineering [PRE01] is the process associated with industrial quality software development, the methods used to analyze, design test computer Software, the management techniques associated with the control monitoring of Software projects the tools used to support process, methods, techniques. In Software Development Life Cycle, the focus is on the activities like feasibility study, requirement analysis, design, coding, testing, maintenance. Feasibility study involves the issues like technical/economical/ behavioral feasibility of project. Requirement analysis [DAV93] emphasizes on identifying the needs of the system producing the Software Requirements Specification document (SRS), [JAL04] that describes all data, functional behavioral requirements, constraints, validation requirements for Software. Software Design is to plan a solution of the problem specified by the SRS document, a step in moving from the problem domain to the solution domain. The output of this phase is the design document. Coding is to translate the design of the system into code in a programming language. Testing is the process to detect defects minimize the risk associated with the residual defects. The activities carried out after the delivery of the software comprises the maintenance phase. 1.2 Evolution of Software Testing Discipline The effective functioning of modern systems depends on our ability to produce software in a cost-effective way. The term software engineering was first used at a 1968 NATO workshop in West Germany. It focused on the growing software crisis. Thus we see that the software crisis on quality, reliability, high costs etc. started way back when most of todays software testers were not even born. The attitude towards Software Testing [BEI90] underwent a major positive change in the recent years. In the 1950s when Machine languages were used, testing was nothing but debugging. When in the 1960s, compilers were developed, testing started to be considered a separate activity from debugging. In the 1970s when the software engineering concepts were introduced, software testing began to evolve as a technical discipline. Over the last two decades there has been an increased focus on better, faster and cost-effective software. Also there has been a growing interest in software safety, protection and security and hence an increased acceptance of testing as a technical discipline and also a career choice. Now to answer, What is Testing? we can go by the famous definition of Myers [MYE79], which says, Testing is the process of executing a program with the intent of finding errors. According to Humphrey, software testing is defined as, the execution of a program to find its faults. Testing is the process to prove that the software works correctly [PRA06]. Software testing is a crucial aspect of the software life cycle. In some form or the other it is present at each phase of (any) software development or maintenance model. The importance of software testing and its impact on software cannot be underestimated. Software testing is a fundamental component of software quality assurance and represents a review of specification, design and coding. The greater visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing. It is not uncommon for a software organization to spend 40-50% of its effort on testing. During testing, the software engineering produces a series of test cases that are used to rip apart the software they have produced. Testing is the one step in the software process that can be seen by the developer as destructive instead of constructive. Software engineers are typically constructive people and testing requires them to overcome preconceived concepts of correctness and deal with conflicts when errors are identified. A successful test is one that finds a defect. This sounds simple enough, but there is much to consider when we want to do software testing. Besides finding faults, we may also be interested in testing performance, safety, fault-tolerance or security. Testing often becomes a question of economics. For projects of a large size, more testing will usually reveal more bugs. The question then becomes when to stop testing, and what is an acceptable level of bugs. This is the question of good enough software. Testing is the process of verifying that a product meets all requirements. A test is never complete. When testing software the goal should never be a product completely free from defects, because its impossible. According to Peter Nielsen, The average is 16 faults per 1000 lines of code when the programmer has tested his code and it is believed to be correct. When looking at a larger project, there are millions of lines of code, which makes it impossible to find all present faults. Far too often products are released on the market with poor quality. Errors are often uncovered by users, and in that stage the cost of removing errors is large in amount. 1.3 Objectives of Testing Glen Myers [MYE79] states a number of rules that can serve well as testing objectives: Testing is a process of executing a program with the intent of finding an error. A good test is one that has a high probability of finding an as yet undiscovered error. A successful test is one that uncovers an as yet undiscovered error. The objective is to design tests that systematically uncover different classes of errors do so with a minimum amount of time effort. Secondary benefits include Demonstrate that Software functions appear to be working according to specification. That performance requirements appear to have been met. Data collected during testing provides a good indication of Software reliability some indication of Software quality. Testing cannot show the absence of defects, it can only show that Software defects are present. 1.4 Software Testing Its Relation with Software Life Cycle Software testing should be thought of as an integral part of the Software process an activity that must be carried out throughout the life cycle. Each phase in the Software lifecycle has a clearly different end product such as the Software requirements specification (SRS) documentation, program unit design program unit code. Each end product can be checked for conformance with a previous phase against the original requirements. Thus, errors can be detected at each phase of development. Validation Verification should occur throughout the Software lifecycle. Verification is the process of evaluating each phase end product to ensure consistency with the end product of the previous phase. Validation is the process of testing Software, or a specification, to ensure that it matches user requirements. Software testing is that part of validation verification associated with evaluating analysing program code. It is one of the two most expensive stages within the Software lifecycle, the other being maintenance. Software testing of a product begins after the development of the program units continues until the product is obsolete. Testing fixing can be done at any stage in the life cycle. However, the cost of finding fixing errors increases dramatically as development progresses. Changing a Requirements document during the first review is inexpensive. It costs more when requirements change after the code has been written: the code must be rewritten. Bug fixes are much cheaper when programmers find their own errors. Fixing an error before releasing a program is much cheaper than sending new disks, or even a technician to each customers site to fix it later. It is illustrated in Figure 1.1. The types of testing required during several phases of Software lifecycle are described below: Requirements Requirements must be reviewed with the client; rapid prototyping can refine requirements accommodate changing requirements. Specification The specifications document must be checked for feasibility, traceability, completeness, absence of contradictions ambiguities. Specification reviews (walkthroughs or inspections) are especially effective. Design Design reviews are similar to specification reviews, but more technical. The design must be checked for logic faults, interface faults, lack of exception handling, non-conformance to specifications. Implementation Code modules are informally tested by the programmer while they are being implemented (desk checking). Thereafter, formal testing of modules is done methodically by a testing team. This formal testing can include non-execution-based methods (code inspections walkthroughs) execution-based methods (black-box testing, white-box testing). Integration Integration testing is performed to ensure that the modules combine together correctly to achieve a product that meets its specifications. Particular care must be given to the interfaces between modules. The appropriate order of combination must be determined as top-down, bottom-up, or a combination thereof. Product Testing The functionality of the product as a whole is checked against its specifications. Test cases are derived directly from the specifications document. The product is also tested for robustness (error-handling capabilities stress tests). All source code documentation are checked for completeness consistency. Acceptance Testing The Software is delivered to the client, who tests the Software on the actual h/w, using actual data instead of test data. A product cannot be considered to satisfy its specifications until it has passed an acceptance test. Commercial off-the-shelf (or shrink-wrapped) Software usually undergoes alpha beta testing as a form of acceptance test. Maintenance Modified versions of the original product must be tested to ensure that changes have been correctly implemented. Also, the product must be tested against previous test cases to ensure that no inadvertent changes have been introduced. This latter consideration is termed regression testing. Software Process Management The Software process management plan must undergo scrutiny. It is especially important that cost duration estimates be checked thoroughly. If left unchecked, errors can propagate through the development lifecycle amplify in number cost. The cost of detecting fixing an error is well documented is known to be more costly as the system develops. An error found during the operation phase is the most costly to fix. 1.5 Principles of Software Testing Software testing is an extremely creative intellectually challenging task. The following are some important principles [DAV95] that should be kept in mind while carrying Software testing [PRE01] [SUM02]: Testing should be based on user requirements: This is in order to uncover any defects that might cause the program or system to fail to meet the clients requirements. Testing time resources are limited: Avoid redundant tests. It is impossible to test everything: Exhaustive tests of all possible scenarios are impossible, because of the many different variables affecting the system the number of paths a program flow might take. Use effective resources to test: This represents use of the most suitable tools, procedures individuals to conduct the tests. Only those tools should be used by the test team that they are confident familiar with. Testing procedures should be clearly defined. Testing personnel may be a technical group of people independent of the developers. Test planning should be done early: This is because test planning can begin independently of coding as soon as the client requirements are set. Test for invalid unexpected input conditions as well as valid conditions: The program should generate correct messages when an invalid test is encountered should generate correct results when the test is valid. The probability of the existence of more errors in a module or group of modules is directly proportional to the number of errors already found. Testing should begin at the module: The focus of testing should be concentrated on the smallest programming units first then expand to other parts of the system. Testing must be done by an independent party: Testing should not be performed by the person or team that developed the Software since they tend to defend the correctness of the program. Assign best personnel to the task: Because testing requires high creativity responsibility only the best personnel must be assigned to design, implement, analyze test cases, test data test results. Testing should not be planned under the implicit assumption that no errors will be found. Testing is the process of executing Software with the intention of finding errors. Keep Software static during test: The program must not be modified during the implementation of the set of designed test cases. Document test cases test results. Provide expected test results if possible: A necessary part of test documentation is the specification of expected results, even though it is impractical. 1.6 Software Testability Its Characteristics Testability is the ability of Software (or program) with which it can easily be tested [PRE01] [SUM02]. The following are some key characteristics of testability: The better it works, the more efficient is testing process. What you see is what you test (WYSIWYT). The better it is controlled, the more we can automate or optimize the testing process. By controlling the scope of testing we can isolate problems perform smarter retesting. The less there is to test, the more quickly we can test it. The fewer the changes, the fewer the disruptions to testing. The more information we have, the smarter we will test. 1.7 Stages in Software Testing Process Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-systems, which are built out of modules that are composed of procedures functions. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation. The most widely used testing process consists of five stages that are illustrated in Table 1.1. Errors in program components, say may come to light at a later stage of the testing process. The process is therefore an iterative one with information being fed back from later stages to earlier parts of the process. The iterative testing process is illustrated in Figure 1.2 and described below: Unit Testing: Unit testing is code-oriented testing. Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components. Module Testing: A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures functions. A module encapsulates related components so it can be tested without other system modules. Sub-system (Integration) Testing: This phase involves testing collections of modules, which have been integrated into sub-systems. It is a design-oriented testing is also known as integration testing. Sub-systems may be independently designed implemented. The most common problems, which arise in large Software systems, are sub-systems interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by rigorously exercising these interfaces. System Testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors that result from unanticipated interactions between sub-systems system components. It is also concerned with validating that the system meets its functional non-functional requirements. Acceptance Testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data. Acceptance testing may reveal errors omissions in the systems requirements definition (user-oriented) because real data exercises the system in different ways from the test data. Acceptance testing may also reveal requirement problems where the system facilities do not really meet the users needs (functional) or the system performance (non-functional) is unacceptable. 1.8 The V-model of Testing To test an entire software system, tests on different levels are performed. The V model [FEW99], shown in figure 1.3, illustrates the hierarchy of tests usually performed in software development projects. The left part of the V represents the documentation of an application, which are the Requirement specification, the Functional specification, System design, the Unit design. Code is written to fulfill the requirements in these specifications, as illustrated in the bottom of the V. The right part of the V represents the test activities that are performed during development to ensure that an application corresponding to its requirements. Unit tests are used to test that all functions and methods in a module are working as intended. When the modules have been tested, they are combined and integration tests are used to test that they work together as a group. The unit- and integration test complement the system test. System testing is done on a complete system to validate that it corresponds to the system specification. A system test includes checking if all functional and all non-functional requirements have been met. Unit, integration and system tests are developer focused, while acceptance tests are customer focused. Acceptance testing checks that the system contains the functionality requested by the customer, in the Requirement specification. Customers are usually responsible for the acceptance tests since they are the only persons qualified to make the judgment of approval. The purpose of the acceptance tests is that after they are preformed, the customer knows which parts of the Requirement specification the system satisfies. 1.9 The Testing Techniques To perform these types of testing, there are three widely used testing techniques. The above said testing types are performed based on the following testing techniques: Black-Box testing technique Black box testing (Figure 1.4) is concerned only with testing the specification. It cannot guarantee that the complete specification has been implemented. Thus black box testing is testing against the specification and will discover faultsofomission, indicating that part of the specification has not been fulfilled. It is used for testing based solely on analysis of requirements (specification, user documentation). In Black box testing, test cases are designed using only the functional specification of the software i.e without any knowledge of the internal structure of the software. For this reason, black-box testing is also known as functional testing. Black box tests are performed to assess how well a program meets its requirements, looking for missing or incorrect functionality. Functional testing typically exercise code with valid or nearly valid input for which the expected output is known. This includes concepts such as boundary values. Performance tests evaluate response time, memory usage, throughput, device utilization, and execution time. Stress tests push the system to or beyond its specified limits to evaluate its robustness and error handling capabilities. Reliability tests monitor system response to represent user input, counting failures over time to measure or certify reliability. Black box Testing refers to analyzing a running program by probing it with various inputs. This kind of testing requires only a running program and does not make use of source code testing of any kind. In the security paradigm, malicious input can be supplied to the program in an effort to cause it to break. If the program breaks during a particular test, then a security problem may have been discovered. Black box testing is possible even without access to binary code. That is, a program can be tested remotely over a network. All that is required is a program running somewhere that is accepting input. If the tester can supply input that the program consumes (and can observe the effect of the test), then black box testing is possible. This is one reason that real attackers often resort to black box techniques. Black box testing is not an alternative to white box techniques. It is a complementary approach that is likely to uncover a different type of errors that the white box approaches. Black box testing tries to find errors in the following categories: Incorrect or missing functions Interface errors Errors in data structures or external database access Performance errors, and Initialization and termination errors. By applying black box approaches we produce a set of test cases that fulfill requirements: Test cases that reduce the number of test cases to achieve reasonable testing Test cases that tell us something about the presence or absence of classes of errors. The methodologies used for black box testing have been discussed below: 1.9.1.1 Equivalent Partitioning Equivalence partitioning is a black box testing approach that splits the input domain of a program into classes of data from which test cases can be produced. An ideal test case uncovers a class of errors that may otherwise before the error is detected. Equivalence partitioning tries to outline a test case that identifies classes of errors. Test case design for equivalent partitioning is founded on an evaluation of equivalence classes for an input condition [BEI95]. An equivalence class depicts a set of valid or invalid states for the input condition. Equivalence classes can be defined based on the following [PRE01]: If an input condition specifies a range, one valid and two invalid equivalence classes are defined. If an input condition needs a specific value, one valid and two invalid equivalence classes are defined. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined. If an input condition is Boolean, one valid and invalid class is outlined. 1.9.1.2 Boundary Value Analysis A great many errors happen at the boundaries of the input domain and for this reason boundary value analysis was developed. Boundary value analysis is test case design approach that complements equivalence partitioning. BVA produces test cases from the output domain also [MYE79]. Guidelines for BVA are close to those for equivalence partitioning [PRE01]: If an input condition specifies a range bounded by values a and b, test cases should be produced with values a and b, just above and just below a and b, respectively. If an input condition specifies various values, test cases should be produced to exercise the minimum and maximum numbers. Apply guidelines above to output conditions. If internal program data structures have prescribed boundaries, produce test cases to exercise that data structure at its boundary. White-Box testing technique White box testing (Figure 1.5) is testing against the implementation as it is based on analysis of internal logic (design, code etc.) and will discover faultsofcommission, indicating that part of the implementation is faulty. Designing white-box test cases requires thorough knowledge of the internal structure of software, and therefore the white-box testing is also called the structural testing. White box testing is performed to reveal problems with the internal structure of a program. A common goal of white-box testing is to ensure a test case exercises every path through a program. A fundamental strength that all white box testing strategies share is that the entire software implementation is taken into account during testing, which facilitates error detection even when the software specification is vague or incomplete. The effectiveness or thoroughness of white-box testing is commonly expressed in terms of test or code coverage metrics, which measure the fraction of code exercised by test cases. White box Testing involves analyzing and understanding source code. Sometimes only binary code is available, but if you decompile a binary to get source code and then study the code, this can be considered a kind of white box testing as well. White box testing is typically very effective in finding programming errors and implementation errors in software. In some cases this activity amounts to pattern matching and can even be automated with a static analyzer. White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that: Guarantee that all independent paths in a module have been exercised at least once Exercise all logical decisions Execute all loops at their boundaries and in their operational bounds Exercise internal data structures to maintain their validity. There are several methodologies used for white box testing. We discuss some important ones below. 1.9.2.1 Statement Coverage The statement coverage methodology aims to design test cases so as to force the executions of every statement in a program at least once. The principal idea governing the statement coverage methodology is that unless a statement is executed, we have way of determining if an error existed in that statement. In other words, the statement coverage criterion [RAP85] is based on the observation that an error existing in one part of a program cannot be discovered if the part of the program containing the error and generating the failure is not executed. However, executed a statement once and that too for just one input value and observing that it behaves properly for that input value is no guarantee that it will behave correctly for all inputs. 1.9.2.2 Branch Coverage In branch coverage testing, test cases are designed such that the different branch conditions are given true and false values in turn. It is obvious that branch testing guarantees statement coverage and thus is a stronger testing criterion than the statement coverage testing [RAP85]. 1.9.2.3 Path Coverage The path coverage based testing strategy requires designing test cases such that all linearly independents paths in the program are executed at least once. A linearly independent path is defined in terms of the control flow graph (CFG) of the program. 1.9.2.4 Loop testing Loops are very important constructs for generally all the algorithms. Loop testing is a white box testing technique. It focuses exclusively on the validity of loop constructs. Simple loop, concatenated loop, nested loop, and unstructured loop are four different types of loops [BEI90] as shown in figure 1.6. Simple Loop: The following set of tests should be applied to simple loop where n is the maximum number of allowable passes thru the loop: Skip the loop entirely. Only one pass thru the loop. Two passes thru the loop. M passes thru the loop where m N-1, n, n+1 passes thru the loop. Nested Loop: Beizer [BEI90] approach to the nested loop Start at the innermost loop. Set all other loops to minimum value. Conduct the simple loop test for the innermost loop while holding the outer loops at their minimum iteration parameter value. Work outward, conducting tests for next loop, but keeping all other outer loops at minimum values and other nested loops to typical values. Continue until all loops have been tested. Concatenated loops: These can be tested using the approach of simple loops if each loop is independent of other. However, if the loop counter of loop 1 is used as the initial value for loop 2 then approach of nested loop is to be used. Unstructured loop: This class of loops should be redesigned to reflect the use of the structured programming constructs. 1.9.2.5 McCabes Cyclomatic Complexity The McCabes Cyclomatic Complexity [MCC76] of a program defines the number of independent paths in a program. Given a control flow Graph G of a program, the McCabes Cyclomatic Complexity V(G) can be computed as: V(G)=E-N+2 Where E is the number of edges in the control flow graph and N is the number of nodes of the control flow graph. The cyclomatic complexity value of a program defines the number of independent paths in the basis set of the program and provides a lower bound for the number of test cases that must be conducted to ensure that all statements have been executed at least once. Knowing the number of test cases required does not make it easy to derive the test cases, it only gives an indication of the minimum number of test cases required. The following is the sequences of steps that need to be undertaken for deriving the path coverage based test case of a program. Draw the CFG. Calculate Cyclomatic Complexity V(G). Calculate the basis set of linearly independent paths. Prepare a test case that will force execution of each path in the basis set. 1.9.2.6 Data Flow based Testing The data flow testing method chooses test paths of a program based on the locations of definitions and uses of variables in the program. Various data flow testing approaches have been examined [FRA88] [NTA88] [FRA93]. For data flow testing each statement in program is allocated a unique statement number and that each function does not alter its parameters or global variables. For a statement with S as its statement number, DEF(S) = {X| statement S contains a definition of X} USE(S) = {X| statement S contains a use of X} If statement S is if or loop statement, its DEF set is left empty and its USE set is founded on the condition of statement S. The definition of a variable X at statement S is live at statement S, if there exists a path from statement S to S which does not contain any condition of X. A definition-use chain (or DU chain) of variable X is of the type [X,S,S] where S and S are statement numbers, X is in DEF(S), USE(S), and the definition of X in statement S is live at statement S. One basic data flow testing strategy is that each DU chain be covered at least once. Data flow testing strategies are helpful for choosing test paths of a program including nested if and loop statements 1.9.3 Grey-Box testing technique Grey box testing [BIN99] designs test cases using both responsibility-based (black box) and implementation-based (white box) approaches. To completely test a web application one needs to combine the two approaches, White-box and Black-box testing. It is used for testing of Web based applications. The Gray-box testing approach takes into account all components ma