Semana 8 e 9 : Software Prototyping The sooner we can provide a visual look and feel of the proposed design, the

better it is for the customer and for the designer. The problem has been that, until recently, we have had no way to create an electronic mock-up of the design without considerable effort, and once that effort was done, designers were reluctant to throw away their work. Now, we have very nice, inexpensive software methods to develop software prototypes that can be easily modified and even thrown away. To get a new product inexpensively to the market, you have to do it quickly. One way to decrease this time is to shorten the design process. Prototyping is an approach for establishing a systems requirements definition quickly and reliably. A prototype is indispensable. Without prototyping it may take weeks or even months, depending on the product and the method used, for customers to view any representation of the system. Rapid prototyping is a method of building prototypes more quickly and more cost-effectively. It is possible to see the real product in an early stage of the process of bringing a new product to the market. This is good for all stakeholders in the system. A software rapid prototype is a dynamic visual model that provides a communication tool for customer & developer that is more effective for displaying functionality than narrative prose or static visual models [9]. The prototype is functional after a minimal amount of effort which provides a physical representation of key parts before system implementation. It is also flexible because modifications require minimal effort. Since we are prototyping pieces, it is not necessary to represent the complete system. Thus, rapid prototyping produces better systems at a lower cost. There are major advantages of taking the time to build prototypes: Prototyping provide insights into alternative design approaches Maintenance costs are reduced since it is more likely that user needs are better met - they can see iterative implementations of the system. Before we had this tool, it was not unusual for customers to be dissatisfied with the initial software implementation and demand that the system be re-engineered because designers and customers had different perspective of requirements. Brooks, in the Mythical Man-Month (chapter 11) suggests that we throw away our first system we build in a project because, as we implement it, we find the things that work and the things that don't work. He suggested that it was much better to throw it away and build it smarter the next time. When he suggested that, most developers were horrified because the tools were not available to do it. Now, our prototyping tools give us this ability.

 Development effort is reduced (cited examples have cost reductions of 45% to 70%).[10] Prototyping gives us an opportunity to do maintenance earlier in life cycle and better clarify customer interface. The rapid (or throwaway) prototyping process is similar to (though not identical with) incremental prototyping in that only those parts of the system which are well understood are developed at first, and the prototype then evolves as the understanding of the whole system becomes clearer. In the context of rapid prototyping for requirements elicitation, however, one would have the intention of terminating this "evolutionary" process once the requirements of the system have been identified. The prototype is thus "thrown away", and it is only the elicited requirements that are retained. Rapid prototyping depends on availability of tools. However, there are now a variety of inexpensive software options. One of the greatest dangers of rapid prototyping is the temptation to try to evolve the prototype into a product when it is poorly designed. In other words, we are not willing to throw away the evolutionary documents or modify them as we find they are inadequate. There is a temptation to allow the prototype to be the specification (which is needed for product design, test design, and maintenance). Another danger is the perception of our customers that they are seeing what appears to be a working system, unaware that the prototype has no depth. Another danger in the opposite direction is that a developer can misconstrue to the customer that the project is further along than it really is. Agile Methods Agile Software Development approach was introduced here during Seminar 2. The goal of this approach is to build software with a lower overhead than the traditional software engineering approaches such as the waterfall approach. Agile is considered a lighter weight and faster software development process best suited for the medium or smaller projects. The Agile movement was identified as a new approach when the Agile Manifesto [15] was published in 2001. According to this Manifesto: 1. highest priority is a satisfied customerby meeting their expectations 2. allows for and, in fact, builds into the process the ability to change requirements 3. delivers software often at regular intervals 4. customers and developers work together throughout the process 5. employ motivated individuals and allow them to get the job done with minimal supervision. 2

6. on-going communication preferably face-to-face 7. completed software is the measure of project progress 8. develops more easily-maintainable code 9. expectation of technical excellence and good design 10. keep it (design and implementation) simple 11. self-organizing teams produce better designs 12. teams evaluate themselves and adjust their behavior accordingly. Agile Manifesto [15] In the lecture last week, the problems associated with requirements elicitation were addressed. It is clear that requirements are ever-changing and unpredictable. This is a serious problem for the traditional software development approaches for several reasons, one important one being the possibility of requirements creep [16] where requirements grow to a point where there is no way to provide clear schedule or cost budgets. Agile Methods addresses this problem with the idea of Iteration complete the development process in phases. In each phase there are milestones which include producing a piece of the working system. With each iteration, customers have the ability to modify the requirements based on the current iteration of the current working system. This is called an adaptive system [17] since the customer can make changes throughout the development process. A side effect of this approach is usually a much closer relationship between the customer and the developers. Customers like this for several reasons. They feel empowered to control the project so it does not get out of hand. They understand the project better and thus do a better job maintaining costs and schedules. So the question which might be asked at this point is why Agile Methods are included in the Prototyping chapter? In a real sense, Agile Methods fits nicely into the idea of evolutionary or incremental prototyping. In evolutionary prototyping, the programming effort for the prototype is reused after the customer has approved the effort. The major difference between the two is one of intent. The Agile Method expects to produce and deliver a full piece of the final project. The evolutionary prototype expects to be a part of the final solution, but is not a full submission of a deliverable. Agile approach to software development is not appropriate for all software development. Large complex projects must have rigid requirements. These types of projects do not do well in the iterative approach to software development. [17] Extreme Programming Extreme programming (XP) was also introduced in Seminar 2. It is included in this chapter of the book because it is an approach replacing traditional prototyping activities. The concepts of XP are discussed in the book. The basic 3

rules of XP fall into four categories: planning, designing, coding, and testing. When you first look at these, it may be difficult to see the differences between XP and other programming activities of a project since they also follow these same rules, but when you examine the activities in each of the categories, you can clearly see the differences [14]: Categories Tasks Planning Design User Stories Identify Release Schedule (small increments) Define the Project Velocity (how fast) Plan the Iterations Designing Make simple designs Define System Metaphors (standards for coders) Create CRC Cards (Class, Responsibilities, and Collaboration ) manages teams Create Spike solutions answers to hard technical questions Refactor evaluate code to eliminate redundancy Maintain access to customer Code written to standards Unit testing done first and integrate often Pair programming used and overtime is discouraged Optimize solutions All code unit-tested and must be passed to be released Acceptance testing is competed often

Coding

Testing

As with any tool, there are advantages and disadvantages. Advantages [17] Project is developed in small incremental phases which is easily accepted by the customer Each stage produces a working system so the customer gets working systems earlier If the requirements change on a project, it is not a problem because the changes can easily be incorporated into the project There is a close working relationship between the customer and the developer.

Disadvantages [19] Good for only certain projects: those with small teams and a committed customer not scalable to large projects. Narrow goal -- XP concerned with the how (coding) not seeing the big picture of the organization Narrow focus of optimization XP finds the most optimal solution in the small, but may overlook the optimal solution for the project.

Rapid Prototyping Techniques It is important that any prototype construction activity be performed as quickly as possible. Three possible techniques that are discussed in the book include dynamic high-level language development environments such as Java or Smalltalk, database programming with tools such as query languages, interface generator, spreadsheets, and report generators, and visual programming with reuse such as Visual Basic or Perl. Another recent, useful prototyping tool is HTML and XML. The advantages of HTML and XML are that everyone has the development tools, the user interfaces can be rapidly developed, and database activity can be simulated. There are many prototyping tools. These tools range from simple wordprocessing tools to sophisticated IDE environments. A developer may use several tools for one implementation. [11] When we develop a prototype, we need to make sure that we follow some simple guidelines: 1. We need to provide access to the functional behavior of the prototype. It is essential that the user interface provide an appropriate means of allowing a customer or developer access to the underlying functional behavior as described by the initial requirements. 2. The interface should be simple to develop and easy to use, thus facilitating comprehension, ease of learning, and a rapid prototype implementation/evaluation cycle. 3. When we develop the prototype we are not implementing the entire system so we dont need to create a full-scale user interface. Instead, just the necessary components are included to provide the developer or customer with just enough functionality. It is undesirable therefore, for the user interface to contain 'frilly' or extraneous details. [12] As we develop the prototype, we dont concern ourselves with all the system constraints. They will be added as we finish implementation. 5

Summary A prototype can be used to give end-users a concrete impression of the systems capabilities. It is becoming increasingly used for system development where rapid development is essential. In fact, rapid development of prototypes is expected in most software development activities.

Notes: [9] Rapid Prototyping Page. Has a variety of helpful links http://www.cc.utah.edu/~asn8200/rapid.html [10] Analysis of Rapid Prototyping. http://osiris.sunderland.ac.uk/rpl/thesis/THESIS1.html [11] Tools and Techniques available for Software Prototyping http://www.itee.uq.edu.au/~comp3500/A3webs/t1a2/ToolsAndTechniques.html [12] User Interface Construction http://www.shu.ac.uk/schools/cms/rapid.software.prototyping/user.interface.construction.ht ml [13] Unified Modeling Language http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci214158,00.html [14] The Rules and Practices of Extreme Programming. http://www.extremeprogramming.org/rules.html [15] Agile Manifesto http://agilemanifesto.org/principles.html [16] Requirements Creep http://searchcio.techtarget.com/sDefinition/0,,sid19_gci860179,00.html [17] The New Methodology Agile http://www.martinfowler.com/articles/newMethodology.html#N400085 [18] A New DACS State-of-the-Art Report on Agile Methods http://www.softwaretechnews.com/stn6-1/agile.html [19] THE DANGERS OF EXTREME PROGRAMMING by Patrick Emery http://members.cox.net/cobbler/XPDangers.htm

URL 1. This site provides a world-wide rapid prototyping directory http://home.att.net/~castleisland/links.htm Tarefas Leituras o Capitulo 17. Para a proxima aula: 2a feira o Resumo dos estudantes o Docente vai escolher estudantes arbitrariamente Questo: para 4a feira e 6a feira (PL)

Extreme programming expressa os requisites do usurio como pequenas histrias, onde cada hiostria est escrita num carto. Analise as vantagens e desvantagens deste mtodo. Exerccios entregar na para 4a feira e 6a feira (PL) Chapter 17 -17.9