How UML and Agile Development Fit Together - Essay Example

?How UML and Agile Development fit together What is software architecture and how is it different from other forms of design? Software architecture is the designing and implementation of high-level structure of software. While other forms of software design are largely about algorithm and data structures, software architecture is mainly about elements, forms, and rationale of the design at a larger scale (Clements et al. 66). Software architecture comes about through assembly of architectural elements in well-chosen forms to satisfy the functionality and performance needs of system. It also satisfies other non-functional system requirement including scalability, portability, reliability, and availability of software. 2. How can software affect both product development and product management? In the current competitive environment, development of products that win the appeal of the customer is very important for success in the market. On the other hand, the success of any product is dependent upon the skills and competencies of the product manager; the latter is responsible for development of products. The product development and management process includes processes such as product requirement definition, release definition, and product life cycles. However, product development and management is complex and includes numerous stakeholders, responsibilities and processes. This means that contemporary product managers have to be heavily assisted by technology, including appropriate software (Gorchels 23). There is need for the right kind and combination of software to be applied for the desired product to be achieved. 3. List and explain the common tasks performed during software architecture. Some of the common tasks performed during software architecture include; Proposal development: A software architect develops proposals for new software based on new product needs or customer requirements. Design: This involves the design and creation of new software on the basis of proposals made. Software realization: This involves supervision of the whole process of software development from design through creation up to the point that the software is ready to be launched. Software validation: A software architect plays the role of validating software for a company especially when such software has been outsourced or is new. This involves ascertaining the effectiveness of the software and ensuring it is fit for purpose. Report writing: The software architect is charged with producing periodic reports during the course of software development. 4. What are the common inputs, constraints, and outputs found during architectural problem solving? Software design inputs are very helpful towards formalization of architecture requirements and constraints. Some of the common inputs in software design include use cases, usage scenarios, functional requirements, non-functional requirements, and technological requirements (Clements et al. 72). Some common constraints in software design include poor technology, fast changing scenarios and unanticipated functional or non-functional requirements. 5. Why is it important for software architects to be familiar with the discipline of requirement engineering? Requirements engineering is mainly concerned with the identification and communication of the purpose of a software-intensive system, and contents in which it will be used. Basically it acts as the bridge between the need of software users, customers, and other groups affected by a software system, and opportunities and capabilities provided by software (Malan and Bredemeyer 1). It is important for software architects to be familiar with requirements engineering because it provides them with the opportunity to understand how to bridge the gap between what users need and system design to meet those needs. 6. What are the four main activities performed during requirement engineering? Explain. The following activities are performed during requirement engineering: Requirements discovery: Involves Requirements analysis: this involves analysis of the utility requirements identified (Both new and existing requirements). The analysis is done with particular consideration of specifications and considering the integrated set of existing and new requirements. Requirements definition: After collection and analysis of a complete and consistent set of requirements, a set of documents systematically detailing all the system requirement specifications is created. The nature of the requirements definition largely depends on user practices. Requirements tendering: This involves the tendering for the work. During this process the suppliers negotiate for amendments which must be acceptable to the utility. An amended requirements document is prepared after this process. 7. List and explain four common quality attributes for software attributes. Some of the most common quality attributes include (Evans 13); Conceptual integrity: this defines the consistency and coherence of an entire design and includes how modules and components are designed. Maintainability: this is the ability of the system to change easily thus enabling changes in features, services, and interfaces. Availability: it is the proportion of time that a system is available and functional. Interoperability: this is the ability of the system or a set of systems to successfully operate by exchanging information with other external systems. 9. What are architectural views and why are they important in software architecture? Architectural views are standardized views that provide useful thinking tools for consideration of decisions and making choices among alternatives. According to Clements et al., architectural views are useful in guiding architects in their decision making; they also serve as the foundation for the architecture specification (complete set of architecture decisions at particular levels of abstraction, specification, and precision)(127). Figure 1 illustrates architecture views. Figure 1: Architecture views 10. Explain Kruchten's 4+1 view model. This is a model of software design that applies five views of the complete architecture. Four of the views provide the description of architecture from different approaches including the logical view, the process view, the physical view, and the development view. The fifth view provides the scenarios and use cases for the software (Evans 32). 11. What are architectural styles and patterns and why are they important in software architecture? In most cases, architectural style and architectural pattern are used to mean the same thing in software architecture. An architectural style makes partitioning easier and promotes reuse of a design by providing solutions to problems that are likely to recur frequently. Architectural styles and patterns are considered as sets of principles that determine the shape of an application (Clements et al., 71). 12. Software architecture is often compared to the architecture of buildings as a conceptual analogy. What are the strong points of that analogy? What is the correspondence in building to software architecture structures and views and patterns? What are the weaknesses of analogy?  The strength of the analogy between software architecture and building architecture lies in the fact that both of them involve the bigger picture of design. Software architecture determines how system components are identified and allocated and how they interact to form the entire system (Malan and Bredemeyer 1). This is more or less like building architecture which determines how different components and aspects of a structure (or set of structures) interact to form a particular building. Just like in building architecture where different structures must be arranged in a particular way to fit the desired pattern and application, system architecture ensures that system components interact in the desired manner to be functional and to fit user needs and desires. The weaknesses of this analogy are that while building architecture produces final designs that cannot be changed, software architecture must be flexible to constant changes and modifications. Works Cited Gorchels, Lawrence. The Product Manager’s Handbook: The Complete Product Management Resource, 3rd ed. New York: McGraw-Hill, 2006. Print Clements, Paul, Rick Kazman, and Mark Klein. Evaluating Software Architectures: Methods and Case Studies (SEI Series in Software Engineering). New York: Addison-Wesley Professional, 2001. Web Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. New York: Addison-Wesley, 2004. Print Malan, Ruth and Dana Bredemeyer. “Architectural Requirements.” Resources for Software Architects Website. Bredenmeyer, 16 Aug. 2002. Web. 8 Sep 2013. Read More