The Representation of African Americans in the Media and...

Introduction In popular culture, specifically American television, representations of African Americans often rely upon an array of stereotypes. Representation is the production of meaning through language or signifying systems. In media, the dominant stereotypes of African Americans include the sapphire, the coon, the jezebel, and the buck. These stereotypes originated during the minstrelsy period of the 1830s from white actors in blackface. While classic Black stereotypes originated during this period, they have carried on past the stage onto the small screen today. Television is a complex site of power where African Americans themselves have enacted these aforementioned stereotypes, particularly in the situation comedy genre. African†¦show more content†¦Also completing the cast are RB singers K.Michelle and Karlie Redd (Love and Hip Hop Atlanta, 2013). The show is known much less for hip hop and much more for its drama. The first season surrounds the love triangle between Stevie J, Mimi, and Joseline. Stevie J’s â€Å"chronic infidelity† has been criticized as a form of abuse (Abrams, 2012). Abrams (2012) gave an opinion piece on The Grio’s website that had received much attention. She believes that showing unhealthy relationships with emotional abuse and chronic infidelity is â€Å"contributing to and condoning a culture of misogyny that sanctions the abuse of black women† (Abrams). She feared that trivializing destructive behavior in entertainment will cause viewers to be unable to handle these behaviors in their own lives. Communication Problem In communication scholarship, there isn’t enough understanding of how reality show audiences feel about what they watch. The purpose in conducting this study is to develop an understanding of how audiences interpret performed identities in reality television. There needs to be more discussion of the present state of reality television. Much of the discussion of African Americans in reality television circle around 2008 when Flavor of Love or Omarosa Manigulat-Stallworth, star of The Apprentice, was on air. Reality television is increasingly becoming the dominant genre of television. Because of it staged version of reality, audience members areShow MoreRelatedHistorical Racial Issues of Broadcast Television699 Words   |  3 PagesCivil Rights Movement, broadcast networks began to face public backlash over the representation of African Americans on television or the lack thereof. In the early 1960s, the NBC affiliate station WLBT in Jackson Mississippi refused to show The Nat King Cole Show or civil rights coverage (Hilmes, 269). Many people were upset by this because it was yet another way for the South to discount the citizenship of African Americans. The FCC ruled that the station had to have a balanced presentation of racialRead MoreSocial Construction And Its Impact On Society Essay1323 Words   |  6 Pagesis created throughout multiple sources and mediums. Thus, due to society’s rapid technological advancement, digital media is one of the primary sources for the creation of social constructions and is now considered the primary account regarding matters connected to mass media. However, it is essential to comprehend that, throughout mass media, individuals commonly referred to as â€Å"media gatekeepers† now present the collective societal groups in an inaccurate depiction. Although these societal groupsRead MoreRace in the Media739 Words   |  3 PagesRace in the media is a very sensitive issue now a days. When it comes to minori ties we can still see that the media portrays us in a bad light. The image of blacks in the American media has changed over the past two decades with the civil rights movement, changes in attitudes towards minority groups, and increased sensitivity on the part of those who and project these images. An examination of the image of Blacks in the articles and advertisements to show attitudes subtly represented, and these attitudesRead MoreAfrican American Stereotypes Reality Television1531 Words   |  7 Pagesof social order and cultural norms to its audiences, while perpetuating racial stereotypes in society (Mendible, 2004). My purpose of the review of literature is to examine and analyze reality television’s influence on people’s perceptions of African American stereotypes. Reality Television Reality based television has a broad landscape ranging from competitive game-like shows to programs following the daily lives of a group of people. Every major network now has some form of reality programmingRead MoreRap Music And Its Influence On African American Youth1705 Words   |  7 Pagesattention of a younger generation. Rap music has undoubtedly had its utmost impact on African American youth, since many of the performers themselves are African American. An overtly masculine culture dominates rap music and creates gender stereotypes that become abundantly popular to the youthful audience. Three constant themes that are found within the rap culture are encouragement of violence, the misogynistic representation of women, an extreme hatred of homophobia. Each theme plays a detrimental roleRead MoreBlack Masculinity Essay1209 Words   |  5 PagesThe article that I will be examines is â€Å"Booty call sex, violence, and images of black masculinity† by Patricia Hill Coll ins. The author has examined the black experience and how the media misrepresents black men; these effects are still felt in the present. Collins was using different forms of media such as sport, film, and historic events. To help the readers to learn where hyper sexuality, violet, and criminal stereotypes of black male come from. Most people in the United States are aware of manyRead MoreTelevision Is A Popular Form Of Media Essay1613 Words   |  7 Pages Television is a popular form of media that permeates the lives of many. It is a staple form of popular culture, enjoyed as a form of escape and distraction from reality. Unlike other forms of media, television is significantly tied to its economic model. Television’s primary purpose is to sell audiences to advertisers, meaning that the purpose of creating a program is to make a large audience who will be forced to watch advertisements during commercial breaks. Without such advertisements, stationsRead MoreAtlanta Is An Fx Original Series Created And Starring, Actor, Comedian, And Musician, Donald Glover Essay1452 Words   |  6 Pageshad a failed attempt at being a rapper still sees the potential in the music industry to provide for himself and his daughter. Within the first minute of the pilot episode you are introduced to World Star Hip-Hop and some common media representations of African American men, in the form of hyper-masculinity and violence, appropriately titling this episode The Big Bang. Donald Glover along with the other writers and producers of Atlanta proves the views with an authentic look into the daily challengesRead MoreAnalysis Of Inuyasha And Othello 1373 Words   |  6 Pages When I was first exposed to Japanese culture, it came through the guise of a popular anime called InuYasha. I was fascinated by the attention to detail and the intricate ways in which the Japanese had woven a tale of death, reincarnation, love, and tragedy into the mold of good versus evil. Most fascinating was the candid role blackness played in constructing the dichotomy between the protagonist (InuYasha) and antagonist (Naraku). Continuously shrouded in darkness the main antagonist, Naraku,Read MoreGrowing Up Where, No One Looked Like Me, : Gender, Race, Hip Hop And Identity Essay1729 Words   |  7 Pagesexamines the dimensions of gender and racialization, this study exemplifies how African-Canadian men and women are constantly faced and conflicted with identity issues. The study conducted interviews with second generation African-Canadians, ages nineteen to thirties. Participants were asked to recall moments from their childhood, in particularly their adolescence, and describe how their peers, pop culture, and their African heritage affected their identity while growing up in predominately white spaces

The Doctrine Of The Trinity - 1583 Words

Like most doctrines of the Church the doctrine of the trinity do not develop fully until there was a need to establish the orthodox view point. The Council of Nicaea determined and stated that Christ and God were separate yet unified, each fully God. This was more of a statement of belief and not theological doctrine. As heresies arouse in regard to the nature of Christ and his relationship to the Father it became more important to develop a theological doctrine that would support the not fully developed orthodox beliefs of the Church that had been taught and believed since apostolic times. This was especially the case with the heresy of Arianism which taught that the Son of God was not co-eternal and consubstantial with His Father, but†¦show more content†¦So the theology to back the Churches beliefs in the trinity fell to several important Church leaders, perhaps the most important of these were Athanasius of Alexandria, Tertullian, Irenaeus, Augustine of Hippo. It was in 325 that the Council of Nicea set out to define the relationship od the Son to the Father in response to Arianism. With the influence of Athanasius this Council affirmed the doctrine of the Trinity as orthodoxy and described Christ as, God of God, Light of Light, very God of very God, begotten, not made, being of one substance (homoousios) with the Father. But it wasn’t the end o the argument regarding the trinity. It was at the First Council to Constantinople in 381 to adopt the theology that we know understand as the Trinity although there were controversies surrounding the trinity into the fifth century. Our understanding of the trinity is that although there is only one God, yet, somehow, there are three Persons in God. The Father is God, the Son is God, the Holy Spirit is God, yet we do not speak of three Gods, but only one God. They have the same nature, substance, and being. Even though the Three Persons are One God, yet they are distinct: for the Father has no origin, He came from no one. But the Son is begotten, He comes from the Father alone. The Holy Spirit comes or proceeds from both the Father and the Son. These different relations of origin tell us there are three distinct Persons, who have one andShow MoreRelatedThe Doctrine Of The Trinity Essay1153 Words   |  5 PagesDoctrine of the Trinity The Trinity is a hard concept for the human minds to fully comprehend. Although the word â€Å"Trinity† is not mentioned in the Bible, there is evidence that God is three in one. Jesus’ baptism described in Matthew 3:13-17 references the Trinity. Matthew speaks of Jesus coming out of the water, the heavens opening, and describing the Spirit of God descending like a dove and a voice from heaven saying â€Å"This is my Son, whom I love.† Also, in Matthew 29:19 it says â€Å"Therefore go andRead MoreThe Doctrine Of The Trinity861 Words   |  4 PagesBefore discussing the Trinity, it is essential to first understand the Doctrine of the Trinity and what it states. Unfortunately for Christians, an exact definition for the Trinity is not provided in the Bible, actually the word ‘trinity’ is never even used in the Bible. Fortunately, however, the Bible is saturated in the belief of a Triune God. The Doctrine of the Trinity states that there is only one G od. The Father, the Son, and the Holy Spirit are all one God, but the Father is not the Son whoRead MoreThe Doctrine Of The Trinity1513 Words   |  7 PagesThe doctrine of the Trinity can be defined as the introduction to the Christian faith. For a number of years, special attention to the doctrine of the Trinity has been given by the educational theologians. The theologians have done lengthy writing on the history of the doctrine development, the relevance of the doctrine in the life of the world and the church. This doctrine was first formally and thoroughly expressed in the fourth century in reaction to alleged alterations of the Bible teachingsRead MoreThe Doctrine Of The Trinity1752 Words   |  8 Pages God as Trinity, is a fact that all orthodox Christians can attest to with absolute certainty, however if we were to ask those same people â€Å"what does that mean for us, how does that affect the way we live our lives†? I suspect, most would not have an answer. For the majority of orthodox Christians, the Trinity is an abstract theological concept, that is best left for theologians to philosophise over, and has no place in the life of the average Christian. Karl Rahner, an Austrian philosopher and theologianRead MoreThe Doctrine Of The Trinity1670 Words   |  7 PagesSince the Nicene Council church patriarchs and theologians have toiled to communicate the principle of the Trinity as a doctrine in the Christian church. Our class readings from Augustine, Thomas Aquinas, Karl Barth, and Elizabeth Tanner reveal the necessity for discussion about the trinity to evolve throughout the last 1500 years of Christian theology in order for the doctrine to be modernized to the lexical and social understanding of contemporary Christians. Although Augustine may be one of theRead MoreThe Doctrine Of The Trinity978 Words   |  4 PagesThe word Trinity cannot be found in the bible, but neither can omnipresent or omniscient; yet they all describe the Biblical expression of who God is and how he is revealed to humanity. Furthermore, the doctrine of the Trinity is so crucial to Christianity, that if it was removed Christianity would crumble and fall into cult status. Even through the doctrine of the Trinity took almost a three hundred to be formally stated at the Council of Nicea (325) and the Council of Constantople (381);1 RogerRead MoreThe Doctrine Of The Trinity1600 Words   |  7 Pages Augustine and the Trinity Introduction The doctrine of the Trinity is often viewed as an archaic and abstract theory many churches and theological study programs settled on long ago, and therefore, has little relevance to modern Christian faith. Over the past fifteen centuries, the doctrine of the Trinity has played a peripheral role in Christian theology. Formulated in Nicea (325 C.E.) and later revised in Constantinople (381 C.E.), it has been generally accepted by most Christians. However, thisRead MoreThe Doctrine Of The Trinity1236 Words   |  5 PagesThe doctrine of the trinity The doctrine of the trinity is the essence and reality of God in his deepest inner life. The trinity is the highest thing that the human brain can contemplate. The doctrine of the trinity is one of the most mysterious theologies in the Christian faith and it is the heart and soul of its teachings. In the trinity there is one true God but three persons. The father, son, and holy spirit. There are misconceptions or heresies going against this belief that there is one GodRead MoreThe Doctrine Of The Trinity1361 Words   |  6 PagesThe doctrine of the Trinity is foundational to the Christian faith. It is crucial for properly understanding what God is like, how He relates to us and how we should relate to Him. The doctrine of the Trinity explains that there is one God who eternally exists as three distinct Persons: the Father, Son, and Holy Spirit. In other words, God exits one in essence but three in person. The Trinity does not divide God into three parts. These definitions express th ree crucial truths: The Father, Son, andRead MoreThe Doctrine Of The Trinity9485 Words   |  38 Pages THE DOCTRINE OF THE TRINITY: Instructor: Lisa Nichols Hickman – hickmanl@duq.edu Director: Father Radu Bordeianu, Ph.D. Course Description: At the center of the Christian faith is a mystery. This mystery has everything to do with the identity of God, the nature of Christian community, the salvation history and our understanding of Christology. This is the mystery of the Trinity – how is the Godhead fully three persons, and yet one nature? Theophilus was the first to name the ‘triad’ nature

Comparing Extreme Programming and Waterfall Project Results Free Essays

Comparing Extreme Programming and Waterfall Project Results Feng Ji Carnegie Mellon University Silicon Valley Campus Mountain View, CA, 94035 jojojifeng@gmail. com Todd Sedano Carnegie Mellon University Silicon Valley Campus Mountain View, CA, 94035 todd. sedano@sv. We will write a custom essay sample on Comparing Extreme Programming and Waterfall Project Results or any similar topic only for you Order Now cmu. edu Abstract Waterfall and Extreme Programming are two software project methods used for project management. Although there are a number of opinions comparing the two methods regarding how they should be applied, none have used project data to clearly conclude which one is better. In this paper, we present the results of a controlled empirical study conducted at Carnegie Mellon University in Silicon Valley to learn about the effective transition from traditional development to agile development. We conducted a comparison research against these two approaches. Multiple teams were assigned a project; some used Waterfall development, others used Extreme Programming. The purpose of this research is to look at advantages and disadvantages based upon the outcomes, generated artifacts, and metrics produced by the teams. 1. Introduction 1. 1. Agile vs Traditional Since the early 1970s, numerous software managers have explored different ways of software development methods (such as Waterfall model, evolutionary model, spiral model etc. ) those have been developed to accomplish these goals and have been widely used by the software industry [1]. Methodologists often describe the Waterfall method as a stereotypical traditional method whereas they describe Extreme Programming as the stereotypical agile method. The Waterfall model, as the oldest traditional software development method, was cited by Winston W. Royce in 1970 [2]. He divided the software development lifecycle into seven sequential and linear stages: Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance. The Waterfall model is especially used for large and complex engineering projects. Waterfall’s lasting impression upon software engineering is seen even in the Guide to Software Engineering Body of Knowledge which introduces the first five knowledge areas based upon their sequence in the Waterfall lifecycle even though the Guide does not recommend any particular lifecycle [3]. Although the Waterfall model has been adopted in many large and complex projects, it still has some inherent drawbacks, like inflexibility in the face of changing requirements [1]. If large amounts of project resources have been invested in requirements and design activities, then changes can be very costly later. High ceremony documentation is not necessary in all projects. Agile methods deal well with unstable and volatile requirements by using a number of techniques of which most notable are: low ceremony documents, short iterations, early testing, and customer collaboration. Kent Beck and Cynthia Andres define Extreme Programming 2. 0 with many practices [4], like Pair Programming, Test First Programming, and Continuous Integration and so on. These characteristics enable agile methods to obtain the smallest workable piece of functionality to deliver business value early and continually improving it while adding further functionality throughout the life of the project [5]. 1. 2. PET project background Carnegie Mellon University Silicon Valley students start their masters program with the Foundations of Software Engineering course. This course is team-based, project-based, and mentored. Each team builds The Process Enactment Tool (PET). The user personas are software developers and managers. The tool helps users plan, estimate, and execute a project plan while analyzing historical data. The tool’s domain encourages students to learn about software lifecycles and methods while understanding the benefit of metrics and reflection. 1. 2. 1. PET 1. 0: In 2001, Carnegie Mellon had one of the largest outsourcing firms in the world develop Pet 1. 0. Later the student teams were brought in to do the next release. The initial offerings of the course had the teams follow a Waterfall lifecycle. The faculty decided to use Extreme Programming as the method for the Foundations course because it was an agile method, it had good engineering practices, and it was a safe sandbox environment for engineers to try paired programming since many managers in industry were initially skeptical about its benefits. In 2005, the faculty allowed three of the sixteen teams tried our new curriculum to see if there were any serious issues in the switch, while other thirteen teams continued to follow a start point in 2004. The feedback was extremely positive so in 2006, all teams followed Extreme Programming. For the project plan duration, Waterfall teams needed fifteen weeks to finish their tasks where as Extreme Programming teams were given only thirteen weeks, a 13% reduction in time. 1. 2. 2. PET 1. 1: In 2005, the VP of Engineering advised the three teams that rewriting the code from scratch would be easier than working with the existing code base. Team 30:1 decided to use the latest in Java technologies including Swing and Hibernate. PET 1. 1, the team’s product became the starting point for the students in the following year. 1. 2. 3. PET 1. 2: In 2008, the faculty switched the core technology from Java to Ruby on Rails. Ruby on Rails’ convention over configuration, afforded a lower learning curve for students. For Pet 1. 2, students would build their projects from scratch. 2. Related work Much research has been done as to when to use an agile method and when to use a traditional method. For example, Boehm Turner’s home grounds look at several characteristics, criticality, culture, and dynamism [6]. Our paper aims to extend these limitations to some degree by estimating Waterfall and XP in an academic case study, which provide a substantive ground for researchers before replicating their ideas in industry. Basili [7] presented a framework for analyzing most of the experimental work performed in software engineering. We learned that how to conduct a controlled experiment. Andrew and Nachiappan [8] reported on the results of an empirical study conducted at Microsoft by using an anonymous web-based survey. They found that one third of the study respondents use Agile methodologies to varying degrees and most view it favorably due to improved communication between team members, quick releases and the increased flexibility of agile designs. Their findings that we will consider in our future work is that developers are most worried about scaling Agile to larger projects, and coordinating agile and traditional teams. Our work is closely related to the work by Ming Huo et al [9]. They compared the Waterfall model with agile processes to show how agile methods achieve software quality. They also showed how agile methods attain quality under time pressure and in an unstable requirements environment. They presented a detailed Waterfall model showing its software quality support processes. Other work has only illustrates one or some Agile practices such as pair programming [10]. 3. Experimental methodology Our research was conducted primarily using Glaser’s steps [11] in the constant comparison method of analysis. Step1: Begin collecting data. We collected more than 50 teams’ detailed data during a five year period as Table 1 shows. Table 1. Team building the same project 2004 2005 2005 2006 2007 2008 Method Waterfall Waterfall XP XP XP XP Language Java Java Java Java Java Ruby Project PET1. 0 PET1. 0 PET1. 0 PET1. 1 PET1. 1 PET1. 2 Numbers of Teams 10 13 3 9 6 11 Step2: Look for key issues, recurrent events, or activities in the data that become categories for focus. The approach in software design makes us categorize the data into two distinctive software development methods, namely Waterfall and Extreme Programming. Step3: Collect data that provides many incidents of the categories of focus with an eye to seeing the diversity of the dimensions under the categories. According to Basili[7], we provided some metrics to compare these two categories, Waterfall and XP. Requirements Metrics M1: Numbers of UI screens (ie. mockup) M2: Numbers of use cases (story cards) M3: Pages of Software Requirements Specification (SRS) documents M4: Pages of User Requirements Documents (URD) Design Metric M5: Pages of detailed design documents Implementation Metrics M6: Lines of code M7: Percentage of lines of comments to lines of source code M8: Lines of test cases M9: Ratio of lines of test code to lines of program code Step4: Write about the categories that we are exploring, attempting to describe and account for all the incidents we have in our data while continually searching for new incidents. Step5: Work with the data and emerging model to discover basic social processes and relationships. Step6: Engage in sampling, coding, and writing as the analysis focuses on the core categories. During 2005, there were 13 teams following Waterfall and 3 teams following XP during the same period of time. These three teams, team Absorb, GT11 and 30:1 are interesting teams to examine as we can compare their data against the Waterfall teams doing the exact same project. 4. Experimental results 4. 1. UI screens (M1) and Story cards (M2) comparison These wide ranges can be seen in Table 2 and Table 3 where the standard deviation of the UI mockups is often half the document size. Comparing use cases to story cards in Table 3, we see that the standard deviation for use cases is much lower than the standard deviation for story cards. This is expected since use cases are a higher ceremony document when compared to story cards. Teams might give little consideration to how to represent each feature on a story card whereas a team writing a use case step by step how a user will use the system will spend much more time thinking about the coupling and cohesion of each use case. Table 2. Average numbers and Standard Deviation of mockups Year 004 2005 Absorb GT11 30:1 2006 2007 2008 Average mockups 15. 5 11. 8 17 18 9 15 12. 8 17. 7 Standard Deviation of mockups 6. 6 6. 3 5. 4 3. 1 8. 8 Table 3. Average numbers and Standard Deviation of use cases/story cards Year Average Number Standard Deviation 2004 User cases 18. 7 2005 User cases 18. 9 2. 3 Absorb Story cards 15 1. 6 GT11 Story cards 13 30:1 Story cards 18 2006 Story cards 16. 6 2007 Story cards 18. 3 2008 Story car ds 16. 6 7. 5 6. 8 8. 0 4. 2. Requirement documents (M3M4) Starting with PET 1. 0, Waterfall teams on average add 1. 7 use cases and modified 2. use cases. Teams were given a 28 page System Requirements Specification (SRS) and on averaged finished with a 34 page SRS. XP teams starting with PET 1. 0 were given the same starting documents. Instead of modifying them, the teams created story cards that represented each new feature. Instead of spending time on writing use cases, XP teams started coding sooner. Because XP has an emphasis on low ceremony documents, they had more time to code resulting in an effort savings for the teams. 4. 3. Comparing the size of the detail design documents (M5) There are some insights from Table 4. Waterfall teams using Pet 1. 0 started with a 21 page Detailed Design Document (DDD), which they altered to reflect their new use cases. Waterfall teams typically did not update their design documents at the end of the project. Given the scope of the project, Waterfall teams’ final code matched the original design with respect to new classes. Table 4. Average pages and Standard Deviation of Detail Design Documents Year 2004 2005 Absorb GT11 30:1 2006 2007 2008 Starting Point 21 21 21 21 0 14 14 0 Average DDD 25. 8 31. 1 18 22 14 18. 3 12. 5 9. 5 Standard Deviation 8. 39 7. 48 7. 70 7. 8 5. 19 XP teams increased their design documents with each iteration. Because the XP teams followed Test-Driven Development, they wrote their code and had an emergent design. At the end of each iteration, the teams were asked to update the design document to reflect important design decisions they had made during that iteration. Therefore, the design document serves a different purpose in XP. It is not a template or blueprint for future construction. Instead, it can be a guide for understanding why certain decisions were made. In this regard, it is a biography of the development, ot a plan of action. 4. 4. New lines of source code and comments, Percentage of comments in codes Table 5 shows that Waterfall teams starting with Pet 1. 0 produced lines of code with a wide variance. The two XP teams starting with Pet 1. 0 fell right within the middle of the average. Because instead of producing some documents up front, the XP teams spent a longer time coding, one would expect them to produce more lines of code. The research results also show that XP Teams had a higher percentage of comments in source code. Table 5. Average and Standard Deviation of new lines in code Year Language Average new lines in code Standard Deviation Lines of test codes Ratio of test codes to program code 2004 2005 Absorb GT11 30:1 2006 2007 2008 Java Java Java Java Java Java Java Ruby 9,429 11,910 13,288 14,689 0 9,628 8,572 3,670 7,946 9,851 4,920 5,465 1,507 3378 4164 1380 3186 947 3555 2212 3,255 8% 13% 4% 8% 8% 16% 10% 90% 4. 5. Submitted lines of test codes and ratio of test code to program code The observation of these two metrics in Table 5 shows that the amount of test code written by the Waterfall teams equals the amount of test code written by the XP teams. Initially the faculty thought that Test-Driven Development would increase the amount of testing code, however, given a slow adoption rate of Test-Driven Development, programmers resorted to what was familiar and thus produced similar results. 5. Conclusion In this paper, we observed and presented the data from five years of 50 teams developing the same project each year and the affects of transitioning from Waterfall to Extreme Programming. The characteristics between these two methods were evaluated and compared. Waterfall teams spent more time creating high ceremony documents where as Extreme Programming teams spent more time writing code and documenting their design in their code. Surprisingly, the amount of code and features completed were roughly the same for both methods suggesting that on a three month project with three to four developers it doesn’t matter the method used. It is challenging to conduct this kind of analysis of the data in hindsight. Given that this is not a toy problem, and the freedom teams have in the execution of their projects, setting up this kind of experiment properly in advance is also challenging. . References [1] Sommerville, Software engineering, 8th ed. , New York: Addison-Wesley, Harlow, England, 2006. [2] W. Royce, Managing the Development of Large Software Systems, IEEE WESTCON, Los Angeles, 1970. [3] A. Abran and J. W. Moore, Guide to the software engineering body of knowledge: trial version (version 0. 95) IEEE Computer Society Press, Los Alamito s, CA, USA, 2001. [4] Kent Beck and Cynthia Andres, Extreme programming eXplained: embrace change, Second Edition, MA: Addison-Wesley, 2004. 5] Mike Cohn, Agile estimating and planning, Prentice Hall Professional Technical Reference, Nov 11, 2005. [6] Barry, Boehm and Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley, August 15, 2003. [7] Basil, V. R. , Selby, R. and Hutchens, D. , Experimentation in Software Engineering, IEEE Transactions on Software Engineering (invited paper), July 1986. [8] Andrew Begel and Nachiappan Nagappan, Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study, MiIEEE Computer Society MSR-TR-2007-09, no. 2007): 10. [9] Ming Huo, June Verner, Muhammad Ali Babar, and Liming Zhu, How does agility ensure quality? , IEEE Seminar Digests 2004, (2004):36. [10] Jan Chong, Robert Plummer, Larry Leifer, Scott R. Klemmer, and George Toye. Pair Programming: When and Why it Works, In P roceedings of Psychology of Programming Interest Group 2005 Workshop, Brighton, UK, June 2005. [11] Glaser, Barney G, Strauss, and Anselm L. , The Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine Publishing Company, Chicago, 1967. How to cite Comparing Extreme Programming and Waterfall Project Results, Papers Comparing Extreme Programming and Waterfall Project Results Free Essays Comparing Extreme Programming and Waterfall Project Results Feng Ji Carnegie Mellon University Silicon Valley Campus Mountain View, CA, 94035 jojojifeng@gmail. com Todd Sedano Carnegie Mellon University Silicon Valley Campus Mountain View, CA, 94035 todd. sedano@sv. We will write a custom essay sample on Comparing Extreme Programming and Waterfall Project Results or any similar topic only for you Order Now cmu. edu Abstract Waterfall and Extreme Programming are two software project methods used for project management. Although there are a number of opinions comparing the two methods regarding how they should be applied, none have used project data to clearly conclude which one is better. In this paper, we present the results of a controlled empirical study conducted at Carnegie Mellon University in Silicon Valley to learn about the effective transition from traditional development to agile development. We conducted a comparison research against these two approaches. Multiple teams were assigned a project; some used Waterfall development, others used Extreme Programming. The purpose of this research is to look at advantages and disadvantages based upon the outcomes, generated artifacts, and metrics produced by the teams. 1. Introduction 1. 1. Agile vs Traditional Since the early 1970s, numerous software managers have explored different ways of software development methods (such as Waterfall model, evolutionary model, spiral model etc. ) those have been developed to accomplish these goals and have been widely used by the software industry [1]. Methodologists often describe the Waterfall method as a stereotypical traditional method whereas they describe Extreme Programming as the stereotypical agile method. The Waterfall model, as the oldest traditional software development method, was cited by Winston W. Royce in 1970 [2]. He divided the software development lifecycle into seven sequential and linear stages: Conception, Initiation, Analysis, Design, Construction, Testing, and Maintenance. The Waterfall model is especially used for large and complex engineering projects. Waterfall’s lasting impression upon software engineering is seen even in the Guide to Software Engineering Body of Knowledge which introduces the first five knowledge areas based upon their sequence in the Waterfall lifecycle even though the Guide does not recommend any particular lifecycle [3]. Although the Waterfall model has been adopted in many large and complex projects, it still has some inherent drawbacks, like inflexibility in the face of changing requirements [1]. If large amounts of project resources have been invested in requirements and design activities, then changes can be very costly later. High ceremony documentation is not necessary in all projects. Agile methods deal well with unstable and volatile requirements by using a number of techniques of which most notable are: low ceremony documents, short iterations, early testing, and customer collaboration. Kent Beck and Cynthia Andres define Extreme Programming 2. 0 with many practices [4], like Pair Programming, Test First Programming, and Continuous Integration and so on. These characteristics enable agile methods to obtain the smallest workable piece of functionality to deliver business value early and continually improving it while adding further functionality throughout the life of the project [5]. 1. 2. PET project background Carnegie Mellon University Silicon Valley students start their masters program with the Foundations of Software Engineering course. This course is team-based, project-based, and mentored. Each team builds The Process Enactment Tool (PET). The user personas are software developers and managers. The tool helps users plan, estimate, and execute a project plan while analyzing historical data. The tool’s domain encourages students to learn about software lifecycles and methods while understanding the benefit of metrics and reflection. 1. 2. 1. PET 1. 0: In 2001, Carnegie Mellon had one of the largest outsourcing firms in the world develop Pet 1. 0. Later the student teams were brought in to do the next release. The initial offerings of the course had the teams follow a Waterfall lifecycle. The faculty decided to use Extreme Programming as the method for the Foundations course because it was an agile method, it had good engineering practices, and it was a safe sandbox environment for engineers to try paired programming since many managers in industry were initially skeptical about its benefits. In 2005, the faculty allowed three of the sixteen teams tried our new curriculum to see if there were any serious issues in the switch, while other thirteen teams continued to follow a start point in 2004. The feedback was extremely positive so in 2006, all teams followed Extreme Programming. For the project plan duration, Waterfall teams needed fifteen weeks to finish their tasks where as Extreme Programming teams were given only thirteen weeks, a 13% reduction in time. 1. 2. 2. PET 1. 1: In 2005, the VP of Engineering advised the three teams that rewriting the code from scratch would be easier than working with the existing code base. Team 30:1 decided to use the latest in Java technologies including Swing and Hibernate. PET 1. 1, the team’s product became the starting point for the students in the following year. 1. 2. 3. PET 1. 2: In 2008, the faculty switched the core technology from Java to Ruby on Rails. Ruby on Rails’ convention over configuration, afforded a lower learning curve for students. For Pet 1. 2, students would build their projects from scratch. 2. Related work Much research has been done as to when to use an agile method and when to use a traditional method. For example, Boehm Turner’s home grounds look at several characteristics, criticality, culture, and dynamism [6]. Our paper aims to extend these limitations to some degree by estimating Waterfall and XP in an academic case study, which provide a substantive ground for researchers before replicating their ideas in industry. Basili [7] presented a framework for analyzing most of the experimental work performed in software engineering. We learned that how to conduct a controlled experiment. Andrew and Nachiappan [8] reported on the results of an empirical study conducted at Microsoft by using an anonymous web-based survey. They found that one third of the study respondents use Agile methodologies to varying degrees and most view it favorably due to improved communication between team members, quick releases and the increased flexibility of agile designs. Their findings that we will consider in our future work is that developers are most worried about scaling Agile to larger projects, and coordinating agile and traditional teams. Our work is closely related to the work by Ming Huo et al [9]. They compared the Waterfall model with agile processes to show how agile methods achieve software quality. They also showed how agile methods attain quality under time pressure and in an unstable requirements environment. They presented a detailed Waterfall model showing its software quality support processes. Other work has only illustrates one or some Agile practices such as pair programming [10]. 3. Experimental methodology Our research was conducted primarily using Glaser’s steps [11] in the constant comparison method of analysis. Step1: Begin collecting data. We collected more than 50 teams’ detailed data during a five year period as Table 1 shows. Table 1. Team building the same project 2004 2005 2005 2006 2007 2008 Method Waterfall Waterfall XP XP XP XP Language Java Java Java Java Java Ruby Project PET1. 0 PET1. 0 PET1. 0 PET1. 1 PET1. 1 PET1. 2 Numbers of Teams 10 13 3 9 6 11 Step2: Look for key issues, recurrent events, or activities in the data that become categories for focus. The approach in software design makes us categorize the data into two distinctive software development methods, namely Waterfall and Extreme Programming. Step3: Collect data that provides many incidents of the categories of focus with an eye to seeing the diversity of the dimensions under the categories. According to Basili[7], we provided some metrics to compare these two categories, Waterfall and XP. Requirements Metrics M1: Numbers of UI screens (ie. mockup) M2: Numbers of use cases (story cards) M3: Pages of Software Requirements Specification (SRS) documents M4: Pages of User Requirements Documents (URD) Design Metric M5: Pages of detailed design documents Implementation Metrics M6: Lines of code M7: Percentage of lines of comments to lines of source code M8: Lines of test cases M9: Ratio of lines of test code to lines of program code Step4: Write about the categories that we are exploring, attempting to describe and account for all the incidents we have in our data while continually searching for new incidents. Step5: Work with the data and emerging model to discover basic social processes and relationships. Step6: Engage in sampling, coding, and writing as the analysis focuses on the core categories. During 2005, there were 13 teams following Waterfall and 3 teams following XP during the same period of time. These three teams, team Absorb, GT11 and 30:1 are interesting teams to examine as we can compare their data against the Waterfall teams doing the exact same project. 4. Experimental results 4. 1. UI screens (M1) and Story cards (M2) comparison These wide ranges can be seen in Table 2 and Table 3 where the standard deviation of the UI mockups is often half the document size. Comparing use cases to story cards in Table 3, we see that the standard deviation for use cases is much lower than the standard deviation for story cards. This is expected since use cases are a higher ceremony document when compared to story cards. Teams might give little consideration to how to represent each feature on a story card whereas a team writing a use case step by step how a user will use the system will spend much more time thinking about the coupling and cohesion of each use case. Table 2. Average numbers and Standard Deviation of mockups Year 004 2005 Absorb GT11 30:1 2006 2007 2008 Average mockups 15. 5 11. 8 17 18 9 15 12. 8 17. 7 Standard Deviation of mockups 6. 6 6. 3 5. 4 3. 1 8. 8 Table 3. Average numbers and Standard Deviation of use cases/story cards Year Average Number Standard Deviation 2004 User cases 18. 7 2005 User cases 18. 9 2. 3 Absorb Story cards 15 1. 6 GT11 Story cards 13 30:1 Story cards 18 2006 Story cards 16. 6 2007 Story cards 18. 3 2008 Story car ds 16. 6 7. 5 6. 8 8. 0 4. 2. Requirement documents (M3M4) Starting with PET 1. 0, Waterfall teams on average add 1. 7 use cases and modified 2. use cases. Teams were given a 28 page System Requirements Specification (SRS) and on averaged finished with a 34 page SRS. XP teams starting with PET 1. 0 were given the same starting documents. Instead of modifying them, the teams created story cards that represented each new feature. Instead of spending time on writing use cases, XP teams started coding sooner. Because XP has an emphasis on low ceremony documents, they had more time to code resulting in an effort savings for the teams. 4. 3. Comparing the size of the detail design documents (M5) There are some insights from Table 4. Waterfall teams using Pet 1. 0 started with a 21 page Detailed Design Document (DDD), which they altered to reflect their new use cases. Waterfall teams typically did not update their design documents at the end of the project. Given the scope of the project, Waterfall teams’ final code matched the original design with respect to new classes. Table 4. Average pages and Standard Deviation of Detail Design Documents Year 2004 2005 Absorb GT11 30:1 2006 2007 2008 Starting Point 21 21 21 21 0 14 14 0 Average DDD 25. 8 31. 1 18 22 14 18. 3 12. 5 9. 5 Standard Deviation 8. 39 7. 48 7. 70 7. 8 5. 19 XP teams increased their design documents with each iteration. Because the XP teams followed Test-Driven Development, they wrote their code and had an emergent design. At the end of each iteration, the teams were asked to update the design document to reflect important design decisions they had made during that iteration. Therefore, the design document serves a different purpose in XP. It is not a template or blueprint for future construction. Instead, it can be a guide for understanding why certain decisions were made. In this regard, it is a biography of the development, ot a plan of action. 4. 4. New lines of source code and comments, Percentage of comments in codes Table 5 shows that Waterfall teams starting with Pet 1. 0 produced lines of code with a wide variance. The two XP teams starting with Pet 1. 0 fell right within the middle of the average. Because instead of producing some documents up front, the XP teams spent a longer time coding, one would expect them to produce more lines of code. The research results also show that XP Teams had a higher percentage of comments in source code. Table 5. Average and Standard Deviation of new lines in code Year Language Average new lines in code Standard Deviation Lines of test codes Ratio of test codes to program code 2004 2005 Absorb GT11 30:1 2006 2007 2008 Java Java Java Java Java Java Java Ruby 9,429 11,910 13,288 14,689 0 9,628 8,572 3,670 7,946 9,851 4,920 5,465 1,507 3378 4164 1380 3186 947 3555 2212 3,255 8% 13% 4% 8% 8% 16% 10% 90% 4. 5. Submitted lines of test codes and ratio of test code to program code The observation of these two metrics in Table 5 shows that the amount of test code written by the Waterfall teams equals the amount of test code written by the XP teams. Initially the faculty thought that Test-Driven Development would increase the amount of testing code, however, given a slow adoption rate of Test-Driven Development, programmers resorted to what was familiar and thus produced similar results. 5. Conclusion In this paper, we observed and presented the data from five years of 50 teams developing the same project each year and the affects of transitioning from Waterfall to Extreme Programming. The characteristics between these two methods were evaluated and compared. Waterfall teams spent more time creating high ceremony documents where as Extreme Programming teams spent more time writing code and documenting their design in their code. Surprisingly, the amount of code and features completed were roughly the same for both methods suggesting that on a three month project with three to four developers it doesn’t matter the method used. It is challenging to conduct this kind of analysis of the data in hindsight. Given that this is not a toy problem, and the freedom teams have in the execution of their projects, setting up this kind of experiment properly in advance is also challenging. . References [1] Sommerville, Software engineering, 8th ed. , New York: Addison-Wesley, Harlow, England, 2006. [2] W. Royce, Managing the Development of Large Software Systems, IEEE WESTCON, Los Angeles, 1970. [3] A. Abran and J. W. Moore, Guide to the software engineering body of knowledge: trial version (version 0. 95) IEEE Computer Society Press, Los Alamito s, CA, USA, 2001. [4] Kent Beck and Cynthia Andres, Extreme programming eXplained: embrace change, Second Edition, MA: Addison-Wesley, 2004. 5] Mike Cohn, Agile estimating and planning, Prentice Hall Professional Technical Reference, Nov 11, 2005. [6] Barry, Boehm and Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley, August 15, 2003. [7] Basil, V. R. , Selby, R. and Hutchens, D. , Experimentation in Software Engineering, IEEE Transactions on Software Engineering (invited paper), July 1986. [8] Andrew Begel and Nachiappan Nagappan, Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study, MiIEEE Computer Society MSR-TR-2007-09, no. 2007): 10. [9] Ming Huo, June Verner, Muhammad Ali Babar, and Liming Zhu, How does agility ensure quality? , IEEE Seminar Digests 2004, (2004):36. [10] Jan Chong, Robert Plummer, Larry Leifer, Scott R. Klemmer, and George Toye. Pair Programming: When and Why it Works, In P roceedings of Psychology of Programming Interest Group 2005 Workshop, Brighton, UK, June 2005. [11] Glaser, Barney G, Strauss, and Anselm L. , The Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine Publishing Company, Chicago, 1967. How to cite Comparing Extreme Programming and Waterfall Project Results, Essay examples