MIT520 software architecture assignments (2012) - 1


Published on

Software Architecture Assignment

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MIT520 software architecture assignments (2012) - 1

  1. 1. MASTER OF SCIENCE IN INFORMATION TECHNOLOGYMALAYSIA UNIVERSITY OF SCIENCE AND TECHNOLOGYSESSION 2012/2013COURSE : SOFTWARE ARCHITECTURECOURSE CODE : MIT520STUDENT NAME : YUDEP APOILECTURE NAME : DR. SELLAPPAN PALLANIAPANASSIGNMENT 1 (20%) DUE DATE: 30 NOV. 2012Retrieve one article (paper) on software design/architecture from any journal, conferenceproceedings or Website. Critique the article, highlighting how the design/architecture hasaddressed the non-functional requirements of the system such as performance, scalability,security, availability and maintainability.MALAYSIA UNIVERSITY ofSCIENCE and TECHNOLOGYCONFIDENTIAL
  2. 2. Critique on Risks and Challenges of Component-Based Software DevelopmentIntroduction:Title: Risks and Challenges of Component Based Software DevelopmentAuthor: Yudep ApoiJournal info: Communications of the ACM, August 2003/vol.46,No.8Summary:In this article, author explain that the risks and challenges of the Component-Based SoftwareDevelopment (CBSD) process. Overall, component developers, application assemblers, andcustomers must know all CBSD advantages and disadvantages before developingcomponents and component-based applications to get maximum benefits from it.The author mention that, practitioners identify the following key CBSD advantages in futuresoftware development efforts: Reduced Lead Time: Complete applications can be built from existing pool ofcomponents. So that one need not fear of developing incomplete applications due tolack of a specific component. Leveraged Cost: As the components developed can be reused in various applicationsthe cost of developing various individual components can be minimized. Enhanced quality: The strengths and faults of the components are pre known as theyare used in many different applications. So quality of the developing applications canbe enhanced. Easy Maintenance: Old components can be replaced with new components forincreased performance.CBSD encompasses three primary types of stakeholders, which are component developers,application assemblers, and customers.
  3. 3. DevelopersA developer encounters certain risks and challenges in developing components, managingcomponent-development projects, and subsequently marketing the components. Developersmust identify business areas or domains that would generate enough yields to justifycomponent development. Developers must adapt to changes in the domain once thecomponents are fabricated. Developers must also determine the optimal way to fragment thedomain into a cohesive set of component. In managing component-development projects, adeveloper must monitor each component from inception to delivery. Developers must alsoassess how often to release components and how to inform clients, or assemblers, of newversions. Before embarking on component-development projects, a developer must conductcost-benefit analyses to determine whether to accept a client, or assembler, and contract orconstruct components for the mass market. Developers must address security issues toalleviate client concerns about possible hacker-prone, corrupt, or virus-infected componentsas well.AssemblerAssembler risks and challenges primarily concern the assembly of components inapplications, the management of component-based application assembly projects, and theuncertainties of the component market. Some crucial challenges in assembling component-based applications that match user requirements include matching system requirementspecifications, demarcating the requirements document into smaller subsets, and confirmingthe overall selected component set. Assemblers must deal with the lack of visibility into thecomponent-development process.CustomersCustomers face both risks and challenges in using component-based applications to meettheir enterprise requirements, as well as in managing their component-based and legacyapplication systems and in achieving and sustaining strategic competitive advantage overtheir rivals. One key risk involves whether a system is capable of satisfying customerrequirements. Customers face additional risks, as application quality (or lack of quality)based on component quality hinders their ability to carry out key business activities. Eachcustomer faces risks in managing its repertoire of component-based applications. Customermust assess which projects are more suitable for CBSD. As assemblers increasingly dependon components developed by developers and customers depend on applications assembled by
  4. 4. assemblers, these risks and challenges propagate from one stakeholder to another. Risks facedby one stakeholder are transferred to the next, ultimately constraining each customer’s abilityto leverage component technology in developing its application systems. While CBSD helpsovercome inadequacies in traditional development, it also poses risks to the profitability andeven long-term survival of each of its stakeholders. Before embarking on component-baseddevelopment projects, each stakeholder must assess its risks and devise sound strategies toaddress them.Strength:The explanations by author clearly stated and its help the software manger to make a betterdecision based on the explanations. It is also can be a guide for the three stakeholders’ withrisks and challenges, and what they should do.This paper explains well about three stakeholders with risks and challenges, and what theyshould do. Cost analysis can be made before hand which avoids running in troubles later.Customers will be able to judge and take right decisions.Weakness:Component developers seem to make some useless components as seen in Figure 1, andassemblers seem to gather some components they need. Developers develop components,which are the first step of project process by CBSD. Of course, component repositories canbecome obsolete because of poor planning or unfavorable industry trends. However,developers try to reduce that kind of problems with better planning and modeling. Securityand privacy issues should be clearly addressed. Responsibility should also be taken in case offailure of the component. Assemblers need to search for different repositories for a specificcomponent. Search cost should also be considered. Trust of the source from where thecomponent selected is also an important issue.Critical Comments & Questions:1. During the estimation cost of the development, are the obsolete component supposed tobe added?2. Should developers and assemblers working together to reduce the obsolete componentand developer’s efforts?
  5. 5. 3. To identify the project that suitable for CBSD do all customers need to know aboutCBSD? If yes, what if they don’t know about CBSD?4. How will the developer know which metric is to be selected in the contract beforemarketing as it cannot be judged beforehand?Interesting Points:I am still developing the project using traditional methodology such as SoftwareDevelopment Life-Cycle (SDLC) and Spiral Model. I would like to follow this methodanother day in the future if I have a chance.Suggestion:To get the overview of the risks involved I suggest strongly that one should read this paperbefore investing on development of any critical component or CBSD projects.