Download AntiPatterns-Patterns in Software Engineering-Lecture 17 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity! Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 17 AntiPatterns Part 2 Department of Computer Engineering 1 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Architectural Stovepipe System/Enterprise: Subsystems/systems are integrated in an ad hoc manner using multiple integration strategies and mechanisms . Cover Your Assets: Document-driven software processes that produce less than useful requirements and specifications because the - - authors evade making important decisions. V d L k I V d L k I i t th t hi hlen or oc − n: en or oc − n occurs n sys ems a are g y dependent upon proprietary architectures. A hi b I li i h l k f hi ifi irc tecture y mp cat on: t e ac o arc tecture spec cat ons for a system under development. Department of Computer Engineering 2 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Architectural – Cover Your Assets Cover Your Assets: Document-driven software processes often produce less-than-useful requirements and specifications because the authors evade making important decisions. In order to avoid making a mistake, the authors take a safer course and elaborate upon alternatives. Solution: Enforce the production of Architecture blueprints: abstractions of information systems that facilitate communication of requirements and technical plans b t th d d le ween e users an eve opers. An architecture blueprint is a small set of diagrams and tables that communicate the operational, technical, and systems architecture of current and future extensions to information systems. A typical blueprint comprises no more than a dozen diagrams and tables, and can be presented in an hour or less as a viewgraph presentation Department of Computer Engineering 5 Sharif University of Technology . Patterns in Software Engineering – Lecture 17 AntiPatterns: Architectural – Vendor Lock−In Vendor Lock In: Occurs in systems that are highly dependent upon − proprietary architectures. A software project adopts a product technology and becomes completely dependent upon the vendor’s implementation. When upgrades are done, software changes and interoperability problems occur, and continuous maintenance is required to keep the system running. Expected new product features are often delayed, causing schedule slips and an inabilit to complete desi ed application soft a e feat esy r w r ur . Solution: Introduce an isolation layer that separates software packages and technology. Department of Computer Engineering 6 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Architectural – Architecture by Implication Architecture by Implication: the lack of architecture specifications for a system under development. U ll th hit t ibl f th j t h i ithsua y, e arc ec s respons e or e pro ec ave exper ence w previous system construction, and therefore assume that documentation is unnecessary. Management of risk in follow-on system development is often overlooked due to overconfidence and recent system successes. Solution: A general architecture definition approach that is tailored to each application system can help identify unique requirements and risk areas. Department of Computer Engineering 7 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Architectural – Reinvent the Wheel Reinvent the Wheel: The pervasive lack of experience transfer between software projects leads to substantial reinvention. “Our problem is unique.” Virtually all systems development is done in isolation of projects and systems with overlapping functionality. Solution: Design knowledge buried in legacy assets can be leveraged to reduce time-to-market, cost, and risk. Department of Computer Engineering 10 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Architectural – Grand Old Duke of York The Grand Old Duke of York: Egalitarian software processes often ignore people’s talents to the detriment of the project . Programming skill does not equate to skill in defining abstractions. There appear to be two distinct groups involved in software development: abstractionists (Architects) and their counterparts the implementationists. According to experts, implementationists outnumber abstractionists approximately 4 to 1 Thus unfortunately abstractionists are often outvoted . , , . Primary consequence: software designs with excessive complexity, which make the system difficult to develop, modify, extend, document, and test. Software usability and system maintenance are impacted by a failure to use effective abstraction principles. S l tio u on: Identifying and differentiating among distinct development roles, and giving architects control over architectural design. Department of Computer Engineering 11 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Management Analysis Paralysis: Striving for perfection and completeness in the analysis phase leading to project gridlock and excessive work on requirements/models. Viewgraph Engineering: On some projects, developers become stuck preparing viewgraphs and documents instead of developing software . Death by Planning: Excessive planning for software projects leading to complex schedules that cause downstream problems. Fear of Success: Often occurs when people and projects are on the brink of success. Some people begin to worry obsessively about the kinds of things that can go wrong. Department of Computer Engineering 12 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Management – Viewgraph Engineering Viewgraph Engineering: Developers become stuck preparing viewgraphs and documents instead of developing software. Organizations with limited technical capabilities for system development are taken at face value because they produce substantive documents and polished briefings. Solution: Verify the development capabilities of the organization and key project staff. Utilize prototyping and mock−ups as part of any system development process. Department of Computer Engineering 15 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Management – Death by Planning Death by Planning: Excessive planning for software projects leading to complex schedules that cause downstream problems. Solution: Deliverable based planning supplemented with validation milestones- , . Plans should be reviewed and revised on a weekly basis. Department of Computer Engineering 16 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Management – Fear of Success Fear of Success: Often occurs when people and projects are on the brink of success. Some people begin to worry obsessively about the kinds of things that can go wrong . Solution: When project completion is imminent make a clear declaration of , success. Department of Computer Engineering 17 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Management – Smoke and Mirrors Smoke and Mirrors: Demonstration systems are important sales tools, but they are often interpreted by end users as representational of production-quality capabilities. Solution: Practice proper ethics to manage expectations, risk, liabilities, and consequences in computing sales and marketing situations . Department of Computer Engineering 20 Sharif University of Technology Patterns in Software Engineering – Lecture 17 AntiPatterns: Management – Project Mismanagement Project Mismanagement: Inattention to the management of software development processes can cause directionlessness and other symptoms. Proper monitoring and control of software projects is necessary for successful development activities. Often, key activities are overlooked or minimized. These include technical planning (architecture) and quality-control activities (inspection and test). Solution: Proper risk management incorporated in the project management process. Department of Computer Engineering 21 Sharif University of Technology Patterns in Software Engineering – Lecture 17 R fe erence Brown, W. J., Malveau, R. C., McCormick, H., Mowbray, T., Antipatterns: Refactoring Software, Architectures, and Projects in Crisis. Wiley, 1998. Department of Computer Engineering 22 Sharif University of Technology