Software Architecture Assignment

1. MASTER OF SCIENCE IN INFORMATION TECHNOLOGY
MALAYSIA UNIVERSITY OF SCIENCE AND TECHNOLOGY
SESSION 2012/2013
COURSE : SOFTWARE ARCHITECTURE
COURSE CODE : MIT520
STUDENT NAME : YUDEP APOI
LECTURE NAME : DR. SELLAPPAN PALLANIAPAN
ASSIGNMENT 1 (20%) DUE DATE: 30 NOV. 2012
Retrieve one article (paper) on software design/architecture from any journal, conference
proceedings or Website. Critique the article, highlighting how the design/architecture has
addressed the non-functional requirements of the system such as performance, scalability,
security, availability and maintainability.
MALAYSIA UNIVERSITY of
SCIENCE and TECHNOLOGY
CONFIDENTIAL

2. Critique on Risks and Challenges of Component-Based Software Development
Introduction:
Title: Risks and Challenges of Component Based Software Development
Author: Yudep Apoi
Journal info: Communications of the ACM, August 2003/vol.46,No.8
Summary:
In this article, author explain that the risks and challenges of the Component-Based Software
Development (CBSD) process. Overall, component developers, application assemblers, and
customers must know all CBSD advantages and disadvantages before developing
components and component-based applications to get maximum benefits from it.
The author mention that, practitioners identify the following key CBSD advantages in future
software development efforts:
 Reduced Lead Time: Complete applications can be built from existing pool of
components. So that one need not fear of developing incomplete applications due to
lack of a specific component.
 Leveraged Cost: As the components developed can be reused in various applications
the cost of developing various individual components can be minimized.
 Enhanced quality: The strengths and faults of the components are pre known as they
are used in many different applications. So quality of the developing applications can
be enhanced.
 Easy Maintenance: Old components can be replaced with new components for
increased performance.
CBSD encompasses three primary types of stakeholders, which are component developers,
application assemblers, and customers.

3. Developers
A developer encounters certain risks and challenges in developing components, managing
component-development projects, and subsequently marketing the components. Developers
must identify business areas or domains that would generate enough yields to justify
component development. Developers must adapt to changes in the domain once the
components are fabricated. Developers must also determine the optimal way to fragment the
domain into a cohesive set of component. In managing component-development projects, a
developer must monitor each component from inception to delivery. Developers must also
assess how often to release components and how to inform clients, or assemblers, of new
versions. Before embarking on component-development projects, a developer must conduct
cost-benefit analyses to determine whether to accept a client, or assembler, and contract or
construct components for the mass market. Developers must address security issues to
alleviate client concerns about possible hacker-prone, corrupt, or virus-infected components
as well.
Assembler
Assembler risks and challenges primarily concern the assembly of components in
applications, the management of component-based application assembly projects, and the
uncertainties of the component market. Some crucial challenges in assembling component-
based applications that match user requirements include matching system requirement
specifications, demarcating the requirements document into smaller subsets, and confirming
the overall selected component set. Assemblers must deal with the lack of visibility into the
component-development process.
Customers
Customers face both risks and challenges in using component-based applications to meet
their enterprise requirements, as well as in managing their component-based and legacy
application systems and in achieving and sustaining strategic competitive advantage over
their rivals. One key risk involves whether a system is capable of satisfying customer
requirements. Customers face additional risks, as application quality (or lack of quality)
based on component quality hinders their ability to carry out key business activities. Each
customer faces risks in managing its repertoire of component-based applications. Customer
must assess which projects are more suitable for CBSD. As assemblers increasingly depend
on components developed by developers and customers depend on applications assembled by

4. assemblers, these risks and challenges propagate from one stakeholder to another. Risks faced
by one stakeholder are transferred to the next, ultimately constraining each customer’s ability
to leverage component technology in developing its application systems. While CBSD helps
overcome inadequacies in traditional development, it also poses risks to the profitability and
even long-term survival of each of its stakeholders. Before embarking on component-based
development projects, each stakeholder must assess its risks and devise sound strategies to
address them.
Strength:
The explanations by author clearly stated and its help the software manger to make a better
decision based on the explanations. It is also can be a guide for the three stakeholders’ with
risks and challenges, and what they should do.
This paper explains well about three stakeholders with risks and challenges, and what they
should 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, and
assemblers seem to gather some components they need. Developers develop components,
which are the first step of project process by CBSD. Of course, component repositories can
become obsolete because of poor planning or unfavorable industry trends. However,
developers try to reduce that kind of problems with better planning and modeling. Security
and privacy issues should be clearly addressed. Responsibility should also be taken in case of
failure of the component. Assemblers need to search for different repositories for a specific
component. Search cost should also be considered. Trust of the source from where the
component selected is also an important issue.
Critical Comments & Questions:
1. During the estimation cost of the development, are the obsolete component supposed to
be added?
2. Should developers and assemblers working together to reduce the obsolete component
and developer’s efforts?

5. 3. To identify the project that suitable for CBSD do all customers need to know about
CBSD? 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 before
marketing as it cannot be judged beforehand?
Interesting Points:
I am still developing the project using traditional methodology such as Software
Development Life-Cycle (SDLC) and Spiral Model. I would like to follow this method
another 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 paper
before investing on development of any critical component or CBSD projects.