University of Texas - SYSM 6325SYSM 6325 Assignment 6.

Document Content and Description Below

Assignment 6 Question 7.1 How do you fit SRS documentation into an agile framework? Answer 7.1: SRS documentation can fit into an agile framework is all necessary parties are involved. This include ... s the necessary stakeholders, requirements engineers, and design engineers weighing in on the wording of requirements. If there are no requirements defined at the beginning of a project or program, SRS documentation can be used to show the evolution of the requirements from the inception of the project through the cycles it goes through to mature. It can be configuration controlled (though that would take more time), or the history of requirements changes can be tracked in a requirements management system such as DOORS. Provided stakeholders are easily available to provide feedback, the SRS documentation can continuously evolve and keep up with the timeline of the agile framework. Question 7.2: Is it possible to use agile methodologies when the customer is not on site? If so, how? Answer 7.2: Agile favors (but does not require) face-to-face communications, with team members committed to the project and able to maintain a constant pace indefinitely. Daily stand-up meetings during the sprint, planning meetings and product demos at the beginning and end of the sprint, and other components of the Agile methodology work best when these assumptions are true. This works great when you can have it. Small businesses with multiple contracts of varying sizes and durations may need to be more flexible, able to change the team as practical demands dictate, and split peoples’ time across multiple projects concurrently. This often gets in the way of the higher degree of team synchronization which Agile favors. Hybrid Methodology Within the confines of what we agree upon with our customers, we often utilize a combination of iterative and more traditional methodologies to get our work done. For instance, we may use a type of sprint internally within the development team as a way of organizing the work. We utilize a backlog and frequent communications (like stand-up meetings) to keep the team moving forward. We conduct sprint reviews with the customer, but may need to limit (or completely curtail) changes. Question 7.3 Why are agile methodologies generally not suitable for hardware-based projects as opposed to software projects? Answer 7.3: Similarities between Hardware and Software Development Software products, hardware products, and combinations of the two in the same product share these characteristics: • They have behavior: Users interact with the products in various ways, products interact with other products, and products produce outputs given inputs • They have functional (user-facing) and non-functional (non-user-facing) requirements • They are complex: Any representation of product specifications invariably leads to a tree structure, as major features are decomposed into finer-grained features Differences between Hardware and Software Development Software and hardware products differ in these ways: • Software is more malleable (easier to change) than hardware. The cost of change is much higher for hardware than for software. • Software products evolve through multiple releases by a process of accretion and refactoring (adding new features and re-writing existing logic to support the new features). Hardware products consist largely of physical components that cannot be “refactored” after manufacturing, and cannot “accrete” newcapabilities that require hardware changes. Designs for new hardware products are often based upon earlier-generation products of similar type, but commonly rely on next-generation components that were not present in earlier generations of the product. • New versions of software and hardware products are both constrained by the design and capabilities of previous versions, but the accretional nature of software development allows for more latitude in deciding what to develop than is the case for hardware. Upgraded versions of hardware products typically have less scope for major qualitative changes, and focus more on quantitative improvements of existing capabilities. • Hardware designs are constrained by the need to incorporate standard parts. • Specialized hardware components can have much longer lead times for acquisition than is true for software. • The design for a hardware product is driven in large part by architectural decisions. As the cost of change is high, more of the architectural work must be done up front compared to software products. 14 • Testing software commonly requires developing thousands of test cases, with perhaps a few to a few tens of new test cases being developed per month over the life of the product. Hardware testing involves far fewer tests, but more specialized and expensive equipment. • Software testing is commonly done by, or defined by, specialized Quality Assurance (QA) engineers, while hardware testing is commonly done by the engineers who are creating the product. • Hardware must be designed and tested to work over a range of time (aging) and environmental conditions, which is not the case for software. • Hardware development incorporates four parallel, synchronized projects: 1) The detailed design of the manufacturable product; 2) the manufacturing process and tooling; 3) the test and inspection process and equipment; and 4) the supply chain for purchased parts. In software development, the detailed design is the product, and production deployment consists of moving the product into a context where it can be used. • The cost of development for software products is relatively flat over time (aside from the usual hiring and attrition). However, the cost of hardware development rises rapidly towards the end of the development cycle for hardware products. • Due to many of the above factors, it is possible to make major changes in direction for a planned software-product upgrade in mid-development, without massive disruption and waste. Attempts to make such changes in hardware development come at a much higher cost, in terms of sunk costs wasted, and shipping schedules postponed. As a result, major changes must either be deferred to a future product upgrade, or are done when an assessment is made that the impact is justified by the magnitude of the benefits. Question 7.4: 7.4 Why can it be difficult for agile methodologies to cover nonfunctional requirements? Answer 7.4:: Basically, non-functional requirements relate to qualities of the system that cut across user facing features, such as security, reliability, and performance. Non-functional is probably a bad name because it sounds like these requirements are intangible, simply properties of a static system. However, these requirements do affect the function of the system and it is possible to design tests that these qualities are present. The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one-shot like a user facing feature. Alternative terms for nonfunctional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements" but let's stick to calling them "non-functional requirement" (NFR) for now. NFR’s are not specified by the business or end customer instead they are considered to be include in the build in agile process but that is not the case. NFR’s are the biggest reasons for long backlogs.There are no clearly defined User stories for NFR;s and no owners for these stories apart from the development team, hence it is mostly difficult to cover NFR’s. 7.6 For the pet store POS system, generate a user story for customer purchases. Answer 7.6: Title: Customer gives back product [Show More]

Last updated: 3 years ago

Preview 1 out of 11 pages