Java Modeling: Child integrated software development, part 2

Java Modeling:Sub-overall software development, part 2		Original ENGLISH

content: Software visibility select an appropriate process software requirements specification Use Case features user scenario conclusion references about the author comment on this article Related content: Java modeling series allArticle XP Essence The Java area also includes: Tutorial Tools and products CodeAnd Components Related Articles Requirement collection: proper process of work Granville Miller (rmiller@togethersoft.com) Consultants and developers, togethersoft October 2001 Granville Miller continued his discussions on child-integrated software development and summarized demand collection in terms of concept. Let's take a look at the four most common requirements collection processes-functional features, user scenarios, use cases, and traditional software requirements specifications-how to adapt to the broader environment of flexible software development processes. Please share your thoughts on this article with the author and other readers in the Forum. In the previous column, I began to discuss sub-overall software development. It is a development method that focuses on process innovation. This is my belief that, as I stated in last month's declaration, sub-overall software development has the potential to make remarkable achievements for developers. However, this does not mean that I advocate the full exclusion process. The philosophy of process can be summarized as follows: There are too few processes. extraordinary people can do ordinary things; There are too many processes. Even extraordinary people cannot do extraordinary things. This month, I will discuss the application of sub-overall software development and processes. In particular, we will talk about requirement collection-the basis of any software development cycle, we will also talk about the sub-overall method-a means to dynamically implement a large number of processes and methods in the development cycle-how to enhance the collection process for your needs. Software visibility issues New software applicationProgramThe difficulty of concept varies with projects. Although the needs of some projects are intuitive-perhaps like applying a new technology to a well-known field-Other project needs may be more complex. When we constantly apply software technology to unknown fields, creating demand for software systems becomes a conceptual innovation. This kind of innovation is not just an individual's complex mental work, but the difficulty is to communicate with larger development groups. Frederick Brooks calls the attributes of new software applications that are hard to generalize and describeSoftware visibility. Although other fields such as hardware have material forms, the software field does not. We can see or evaluate the effects of software applications, but their system forms are essentially thinking. This is one of the many reasons we have created and relied on the software model. The model gives the software physical dimension so that we can better understand and express its direction. The center of any software modeling is requirement collection. The selection of the requirement collection process depends on the larger environment of the development project. This environment can be found in the requirement collection process, or in another well-received model. In some cases, this environment can even be found during the delivery process. By examining the possibilities of different requirements, we can always identify where the system's Demand Environment resides. The demand environment is our field of confrontation against the visibility of software. Proper Work Process Selection Collection of selected requirements greatly affects the success of software development projects. Because requirement collection is the basis of the development cycle, an invalid or improperly selected requirement analysis process greatly increases the possibility of project failure. This possibility leads us to stick to the known process, usually related to a separate, preferred software development method. The requirement collection process will be abstracted from three first-class software development methods: "Rational Unified Process" (RUP )), feature-driven development (FDD) and extreme programming (XP )). Each method provides a large number of excellent tools to assist in demand collection. To comply with the sub-overall development method, we will focus more on the necessary part-the collection process of requirements related to each method-rather than the entire method itself. In addition, we will also see if we can organize a more dynamic and variable requirement collection process. Before continuing the discussion, please take some time to read this supplementary article "ten sub-overall software development guidelines" to see how the sub-overall method includes what we know in theory. The four most common requirements collection processes are the traditional software requirements specification (SRS), use cases, and feature features) and user stories ). In the following sections, we will consider each process. Pay special attention to the requirement environment-that is, each process provides the appropriate circumstances for maximizing value and the unique motivation that each process brings to the development project. For more information about the application of each process, see references. Software Requirements Specification Software Requirement Specification (SRS) is one of the oldest requirement collection processes. Its informal name is "shall statements". The traditional SRS have many forms, and it is still needed for contracting projects in many fields today. SRS has been a dominant demand collection method for many years. The idea behind SRS is to create a solution space, that is, a space where the development team has set goals, but the order and nature of actions to achieve these goals can be very free. Therefore, SRS generally does not specify a single solution, but a series of feasible solutions. Then, the development team is flexible enough to innovate effective methods to solve the problems of the systems being created. Flexibility is a disadvantage and advantage for SRS. If a software development team is proficient in the field where they create systems for it, the Group can easily use SRS to maximize innovation in this field. However, in the era when development teams do their daily work in areas they are not familiar with, the traditional SRS collection process as demand may be lacking. When a typical user attempts to handle normal conditions in a given domain, the steps they take are likely not understood by the group members. Therefore, the system determined and created by the team members isCommunityIt may not be optimal. The traditional SRS is most suitable for development environments that have been fully understood and that have very good knowledge of the areas in which they work-or that have a very easy understanding of professional knowledge outside of the field. SRS allows you to adjust the solution space to manage changes in the system without any technology. Use Cases Compared with the solution space method supported by the traditional SRS, use cases describe the sequence of actions executed when users interact with the system. In a sense, use cases are based on routes or purposes. It conveys a series of actions that users must start when using the system to solve the problem. For example, in a "video rental" case, we describe what happens when users interact with the video rental system. Use Cases reflect all events that may occur when we try to use the software system for the purpose. Because most software systems support multiple purposes, most use case models consist of multiple use cases. For example, the "pay late fee" case describes what happens when a video rental system user needs to pay the overdue payment. The correct level of information in the use case is a prerequisite for successful application creation. It varies depending on the environment. If experts in the field participate in the development process, use cases can only outline the system route. If field experts are not involved in the project, it is necessary to provide more information for use cases. Use Cases are the best process for communication requirements. However, like the traditional SRS, use cases are more suitable for fields that have been well understood. Use Cases can be changed to a certain extent, but other processes can better adapt to changes. videotape rental use cases the following use cases are used to define automatic (web-based) the best route for customers in the video rental solution. Use Case name : rental videotape unique use case id : vs-01 main participants : Customers secondary participants : n/A brief description : This example describes the interaction behavior of a customer when renting a videotape Based on the Web. trigger event : the customer selects the title from the title directory. prerequisites : the customer must have an active account. the customer shall meet the grading age requirements of the videotape attached to the title directory. the title directory is provided with the title. event stream : the customer browses the title directory and selects a name. if this title exists, the system adds the media corresponding to this title to the shopping cart, and the media is waiting for rent. after the customer completes the media selection, he places an order. To place an order, you must allow the customer to pass authentication and ensure that the account is valid. The media fee is credited to the borrower (system) from the user account ). The order-related media in the shopping cart is converted to "rented ". the system confirms the order. subsequent conditions : Create a new order for this account. modify the inventory to reflect the rented videotape. the system has credited the account to the borrower (system) and credited the transaction to the customer based on the video price ). optional event streams and exceptions : the title does not exist: the customer must make another choice. the account is invalid because the overdue payment is not paid. For details, refer to the "payment overdue payment" case. invalid account due to invalid credit card: The system prompts the user to enter a valid credit card account. Features Features are a brief description of the system's expected functions. Feature format: <Action> the <result> <by | for | of | to> A (n) <Object> The features of an example can be: Forecast the total of quarterly sales. When each feature is kept at a minimum, the method based on the feature works best. The functional features that a group can achieve within two weeks or less are ideal features. Use the nameFeature set(Feature set) groups organize functional features. A feature set contains functional features that describe a given purpose or domain. The feature set and its features only outline the requirements. As a mechanism to describe requirements, features must be combined with additional environments. In the "function-driven development" method, the environment is carefully designed to be between a feature set and aField neutral component"(Domain neutral component) between color labels. The domain neutral component is a semantic template describing cross-domain public relations. The domain neutral component consists of the moment-interval, role, subject, party, location, or transaction, and description.Instant IntervalIt is a short-term element in those fields, such as an order in the ordering execution system.RoleIs a user, the system interacts with him and must be able to identify him.TopicIs an element in the formation of a domain.DescriptionIs an abstraction that aggregates the metadata of these objects. Figure 1 is a field-neutral component for video rental. Figure 1. Domain-neutral components of the videotape rental Solution As a requirement collection process, "feature-driven development" is very flexible and helps change management during the development cycle. This process allows you to easily check and record the number of new, changed, and removed feature features during the project. In general, because the features are small, changing existing features or adding new features is unlikely to require a large amount of rework at the project level. Feature features also help to challenge the visibility of software, as new features that may be revealed as tracking the interaction results between system entities in neutral components in the field. Features can be used to familiarize yourself with individual needs in a given field. In this way, the feature-based method may be the most economical requirement collection process. However, these features may be too dependent on field expertise, which is a luxury that many development teams do not have. User scenario A user scenario is a brief description written on the index card, as shown in figure 2. Figure 2. Key Points of sales user scenarios A user scenario usually contains more information than a feature, although this is not necessary. In the "extreme programming" method, user scenarios require a field customer to provide part of the environment. Field customers describe the ideal system to the development team. Then, the team established a system at, giving the customer ample opportunity to regularly view the results. The customer "supervises" the delivery and use process, and proposes modifications to the system in the new user scenario. The entire environment is combined with on-site customer feedback and incremental process and delivery. User scenarios are the best way to handle projects with the highest risk of software visibility. Like feature, they are small enough to be easily changed. Because their environments are based on operating systems and customers, once implemented or no longer valid, they will be discarded. However, not every project can introduce on-site customers, so user scenarios are not suitable for each project. This method loses its advantage due to its lack of customer interaction. Conclusion Each requirement collection process discussed in this article has its advantages in an appropriate environment. However, as discussed in this article, not every requirement collection process is ideal for each environment, and they are not even necessary and complete. Child-integrated software development is centered on recognizing the inherent incompleteness of a single process or activity and maximizing the scope of these solutions to reduce such incompleteness. In addition, the article "Ten Best criteria for sub-overall software development" is discussed.Adequacy. Vigilance allows two activities with the same purpose to replace each other. When one requirement collection activity is used instead of the other, it is important to consider the demand environment. Changing activities during the development cycle is likely to introduce a new set of motivation to the project. If the environment is not taken into account, such actions may become disasters. However, after careful planning and implementation, the introduction of new activities can help to create new impetus, thus promoting the success of the project. Next month, let's talk about Web service infrastructure modeling. As we investigate this emerging field of software development, I will provide more detailed technical examples and the best principles that have been discussed in the last two columns, so please do not leave! References Please join this forum. for more information about use cases, see the advanced use case modeling homepage written and maintained by Frank armour and Granville Miller. Jeff De Luca provides an Optimal introduction to the FDD origin in his article "the original FDD processes. new XP beginners may need to first read the "XP essence" written by Roy Miller and Chris Collins (developerworks, March 2001 ). extreme programming.org is a treasure house of a large number of reference materials by XP enthusiasts. It briefly introduces the user scenario roles in the XP development process. user-centered design (UCD) is a user scenario that is similar to the requirement collection and feedback process, but has a wider scope. Find out how to use the cheap and low-cost "fly on the wall" method (developerworks, August 2001) to learn what users need. On the IBM users of use homepage, you will find more references suitable for user-centric design. read all the "Java modeling" columns in the "Java modeling" archive file (including the sub-overall Software Development Declaration last month ). Please find more java references in the developerworks Java technology area. about the author Granville has more than 10 years of experience in the object-oriented community. He is a co-author of the advanced case modeling series and has introduced tutorials at various object-oriented technical conferences around the world. His practical method of object-oriented development comes from his experience working in a number of companies, including various companies from startups to mature software giants. He is currently teaching workshops, tutorials, and courses on flexible processes, methods, and Java technologies, as well as tutoring and helping implement some useful projects. Please contact Granville via rmiller@togethersoft.com.