RW-03

Upload
0
Embed
Share
Upload and view presentations on any device and embed the player to your website! --- > >
Upload PPT
Upload PPT

wahyusinduprasetya

2022-3-16 published at Education&Career category

Presentation Transcript

1.COMMUNICATION STMIK Pontianak Prepared by Amar P. Natasuwarna
2.REFERENCES
3.WebE Process Flow
4.Begin with the Communication The WebE process begins with the communication activity. Referring to Figure 4.1, communication serves as the entry point for the process flow. It is the place where Web engineers and stakeholders engage in a series of WebE actions that: formulation to ask and answer a set of fundamental questions about the WebApp and its business context, elicit requirements that will serve as the basis for all activities that follow, negotiate needs against the realities of time, resources, and technology. These actions are called formulation, elicitation (also called requirements gathering), and negotiation, respectively
5.Formulation Formulation is a WebE action that begins with the identify cation of a business need, moves into a description of WebApp objectives, defines major WebApp features, and establishes a basis for the elicitation action that follows. Formulation allows stakeholders and the WebE team to establish a common set of goals and objectives for the creation of each WebApp increment. It also identifies the scope of the development effort and provides a means for determining a successful outcome.
6.Who Should You Communicate With? You’ll need to identify stakeholders. A stakeholder can be defined as “anyone who benefits in a direct or indirect way from the system which is being developed” [Som97]. This individual will have appropriate business experience, good technical knowledge, and the authority to negotiate needs in terms of delivery time and resources. You’ll deal with a number of different stakeholders, each with a different point of view, sometimes diverging needs, and substantially different business and technical knowledge. In general, stakeholders are drawn from the following categories: business managers, product managers, marketing people, internal and external customers, end users, consultants, product engineers, Web engineers, and support and maintenance staff
7.What Techniques Can You Use for Communication? Traditional focus group. A trained moderator meets with a small (usually fewer than 10 people) group of representative end. Electronic focus group. A moderated electronic discussion conducted with a group of representative end users and stakeholders. Iterative surveys. A series of brief surveys, requesting answers to specific questions about the WebApp, is conducted via e-mail. Exploratory survey. A Web-based survey is tied to one or more WebApps that have users who are similar to the ones who will use the WebApp to be developed. Scenario building. Selected end users are asked to create usage scenarios that describe specific interactions with the WebApp.
8.Won’t There Be Different Viewpoints? Every stakeholder has a different view of the WebApp, achieves different benefits when the WebApp is successfully deployed, and is open to different risks if the development effort should fail. For example: Business managers are interested in the feature set that will result in sales growth and improved revenue for the company. The marketing group is interested in features that will excite the potential market, leading to new customers and increased sales. The product manager wants a WebApp that can be built within budget and that will be ready to meet defined market windows. End users may want features that are already familiar to them and that are easy to learn and use. Web engineers may be concerned with functions that are invisible to nontechnical stakeholders but that enable the infrastructure that supports more marketable features. Support engineers may focus on the maintainability and extensibility of the WebApp.
9.What Questions Should We Ask? What is the main motivation (business need) for the WebApp? What are the objectives that the WebApp must fulfill? Who will use the WebApp?
10.SAFEHOME Answers SafeHomeAssured.com will allow customers to evaluate, configure, and purchase security system products and monitoring services. SafeHomeAssured.com will allow us to sell directly to consumers, thereby eliminating middleman costs and improving our profit margins. It will also allow us to increase sales by a projected 25 percent over current annual sales and will allow us to penetrate geographic regions where we currently do not have sales outlets. It will reduce the need for expanding our customer service call center by providing features that allow a customer to access monitoring information directly. Projected end users (the primary demographic) of SafeHomeAssured.com are homeowners and owners of small businesses. However, the application will also be used by CPI sales and service staff.
11.Goals Information of SAFEHOME To allow the user to learn about CPI Corporation, its people, and products To provide users with detailed product specifications, including technical descriptions, installation instructions, and pricing information To display the security configuration (including all hardware) for the facility (house or business) that the end user define To enable a user to obtain a quote for product cost To create an account database that provides account information for customers
12.Finishing Formulation Once all informational and applicative goals have been identified, a user profile is developed. The user profile captures “relevant features related to potential users including their background, knowledge, preferences and even more” . A user profile would identify the characteristics of a typical purchaser of security systems. Once the WebApp objective, goals, and user profiles have been developed, the formulation activity focuses on a statement of scope. In many cases, informational and applicative goals provide sufficient information to identify the scope of the problem
13.How Do We Encourage Collaboration? If five stakeholders are involved in a WebApp project, we have five (or more) different opinions about the proper set of requirements. Stakeholders should collaborate among themselves and with Web engineers if a successful system is to result. But how is this collaboration accomplished? Our job is to act as a consultant during formulation and elicitation—to identify areas of commonality (i.e., requirements on which all stakeholders agree) and areas of conflict or inconsistency (i.e., requirements by one stakeholder but conflict with another stakeholder). It is, of course, the latter category that presents a challenge.
14.SAFEHOME: Prioritizing WebE
15.Basic Guidelines to Requirements Gathering A meeting is conducted and attended by all stakeholders. Rules for preparation and participation are established. An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas. A facilitator (can be a customer, a Web engineer, or an outsider) controls the meeting. A definition mechanism (can be work sheets, flip charts, wall stickers, an electronic bulletin board, chat room, or virtual forum) is used.
16.What Happens Before an Elicitation Session? During formulation, basic questions and answers establish the WebApp scope and provide some insight into WebApp features. If the scope indicates a significant development effort, preparation is advisable before any requirements gathering is conducted. If time permits, you might consider writing a one-page WebApp description that will serve as the basis for requirements gathering. The WebApp description is assembled using the information already derived from the formulation meeting.
17.SAFEHOME: WebApps Description SafeHomeAssured.com will allow CPI Corporation to market and sell security products and monitoring services directly to consumers, thereby eliminating middleman costs and improving our profi t margins. To accomplish this goal, the WebApp will incorporate both content and functions that implement the following product-related features: End users can examine the SafeHome product line and request product specs. Users can configure a security system by representing the layout of a “space” (i.e., house, offi ce/retail space) and then initiating functions within SafeHomeAssured.com to make customized recommendations about security and monitoring products that can be used within the space. Users can request an instant quote for product and/or system pricing. • Users can place an order for sensors, controllers, audio, and video hardware and related infrastructure.
18.SAFEHOME: Monitoring Security Basis Users can sign up for monitoring services, order installation of a SafeHome system, and coordinate all other setup activities that will lead to a purchase of security products, their installation, and the execution of a monitoring contract with CPI. Contract customers can control security and monitoring equipment within their space and use the SafeHomeAssured.com WebApp to acquire the output of security devices and display them. Customers can query the CPI monitoring database about their account activity
19.How Do Stakeholders Prepare? Each stakeholder is asked to review the WebApp description before the requirements gathering meeting and make a list of “content objects” that are: (1) part of the environment that surrounds the system, (2) produced by the system, and (3) used by the system to perform its functions. In addition, each attendee is asked to make a list of functions that manipulate or interact with the content objects. Finally, lists of constraints (e.g., business rules that will impact the features provided) and performance criteria (e.g., speed, accuracy, privacy, security) are also developed. The attendees are informed that the lists are not expected to be exhaustive but are expected to refl ect each person’s perception of the system.
20.SAFEHOME: Content objects described
21.SAFEHOME: List of Functions
22.What Tasks Are Performed During an Elicitation Session? Define user categories, and develop descriptions for each category. Refine content and functionality using the lists each person prepared. Consider specific constraints and performance issues. Write user scenarios for each user class.
23.Define a User Category What is the user’s overall objective when using the WebApp? For example, one user of SafeHomeAssured.com might be interested in gathering information about home management products. What is the user’s background and sophistication level relative to the content and functionality of the WebApp? If a user has a technical background and significant sophistication, elementary content or functionality will provide little benefit. How will the user arrive at the WebApp? Will arrival occur through a link from another website or search engine (this is likely to influence the design of the content and functionality within the WebApp) or will arrival occur in a more controlled manner through the home page? What generic WebApp characteristics does the user like and dislike? Different types of users may have distinct and predictable likes and dislikes. It’s worth attempting to determine whether they do or do not.
24.SAFEHOME: Requirement Meeting
25.How Are Constraints and Performance Issues Isolated? Internal constraints relate to the technical environment in which the WebApp will reside and the project environment will be built. The technical environment might uncover specialized database protocols, the different Web browsers, and operating system characteristics. The project environment encompasses available WebE tools, development hardware, software standards, and staff skill levels. External constraints relates to business rules, end-user idiosyncrasies, security demands, privacy issues, run-time performance, interoperability requirements, legal restrictions, and government regulations.
26.SAFEHOME: User Scenario
27.What Are Use Cases? Use cases are a widely used approach for the creation of user scenarios. Use cases describe how a specific user category (called an actor) will interact with the WebApp to accomplish a specific action. The action may be as simple as acquiring defined content or as complex as conducting detailed user-guided control of remote monitoring equipment. The use case describes the interaction from the user’s point of view. In general, use cases are developed iteratively. Only those use cases necessary for the increment to be built are developed during the communication activity for the increment. In many situations only use cases for major WebApp functions (those considered during requirements gathering) are considered. These use cases may be refined during the analysis modeling activity (Chapter 7) for the increment.
28.Benefits of Use Case Use cases provide the detail necessary for effective planning and modeling activities. Use cases help the developer to understand how users perceive their interaction with the WebApp. Use cases help to compartmentalize Web engineering work because they can be organized into WebApp increments. Use cases provide important guidance for those who must test the WebApp.
29.Use Case: Access Camera
30.Usage Scenarios by Cards
31.SAFEHOME: Incremental
32.
33.Negotiation Ideally, communication determines stakeholder requirements in sufficient detail to proceed to subsequent framework activities for an increment. In reality, web engineers and other stakeholders often enter into a process of negotiation, where a stakeholder may be asked to balance functionality, performance, and other product or system characteristics against cost and delivery time. The intent of this negotiation is to establish increment requirements that meet the needs of the customer while at the same time reflecting the real-world constraints. The best negotiators strive for a win-win result. That is, the customer wins by getting a WebApp that satisfies the majority of his or her needs, and the WebE team wins by working toward realistic and achievable deadlines. Before any negotiation begins, it’s a good idea to determine each of the stakeholders’ “win conditions” and to develop a strategy that will reconcile them into a set of win-win conditions for all concerned (including the WebE team).
34.SAFEHOME: Negotiating Requirement
35.Thanks! Do you have any questions? amar.natasuwarna@stmikpontianak.ac.id STMIK Pontianak Please keep this slide for attribution

Latest Release