MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_01C59055.320A6890" This document is a Single File Web Page, also known as a Web Archive file. If you are seeing this message, your browser or editor doesn't support Web Archive files. Please download a browser that supports Web Archive, such as Microsoft Internet Explorer. ------=_NextPart_01C59055.320A6890 Content-Location: file:///C:/8E8B314E/BSA400_ERPDesign.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Running head: DESIGN PHA= SE OF AN ENTERPRISE-LEVEL BUSINESS SYSTEM
Design Phase of an Enterpri= se-Level Business System
Design Phase of an Enterpri= se-Level Business System
The Design Phase of an Enterprise-Level Business System occu= rs after the Analysis Phase, and is where careful plans become actual details.= As author Martin Modell explains, “Systems analysis is the decomposition= of the current environment into its component pieces for examination and study. The design process is development of a plan for the building up of a larger harmonious unit from component parts” (Modell, 2003). In this paper, I= will examine a particular methodology and tool available to the developer in the Design Phase.
“The objective of the Design Phase is to transform the detailed, defined requirements into complete, detailed specifications for t= he system to guide the work of the Development Phase” (Maryland Department of Budget & Management, 2002, chap. 5). Various methods exist to help the developer during this important phase that incorporate common characteristics. Howeve= r, these evolving methods require reconfiguring to meet the requirements of individual organizations. “As these methods become more widespread, m= ore widely adopted, and integrated into the software development life cycle, organizations inevitably will want to tailor them. Consequently, organizati= ons that wish to include quality-attribute-based requirements, explicit architecture design, and architecture analysis in their software development life cycles will be best served if they can do so organically” (K= azman, Nord, & Klein, 2003). Successful developers give careful considerat= ion as to which methodology to employ, and to which methodologies to reconfigur= e to suit the organization’s needs.
The different components included in any system design are i= nput, output, processing, and files. Mapping these components and their relations= hip to each other is important before actual programming begins. “The exceptional or foolish programm= er might begin coding without a good design. Programmers who do so may find themselves going back to modify pieces of code they've already written as t= hey move through the project” (= Thompson Course Technology, n.d.). The input and output requirements are especia= lly important to the overall system design, as these constraints often determine which methodologies to use during the Design Phase.
Over the past ten years, several architecture-centric analys= is and design methods became available. These methodologies evolved to meet the requirements of the organizations employing them in both Analysis and Design Phases. These methodologies, in no particular order, include Quality Attrib= ute Workshop, or QAW; Cost-Benefit Analysis Method, or CBAM; Active Reviews for Intermediate Design, or ARID and Attribute-Driven Design, or ADD= . While this list is not exhaustive, it includes predominate examples (Kazman et al., 2003). From this= list, I will examine the Cost-Benefit Analysis Method, or CBAM, as it is representative of all methods.
The Cost-Benefit Analysis Method “helps the systemR=
17;s
stakeholders to choose among architectural alternatives for enhancing the
system in design or maintenance phases” (Kazman et al., 2003). This meth=
od,
more than the others, examines the overall benefits and risks associated wi=
th
the system in terms of cost. “The CBAM enables users to make informed
software requirement and software investment decisions based upon an analys=
is
of the economic and architectural implications of those decisions” (, 2005). This
methodology offers the programmer and organization a process for analyzing =
the
financial benefits of the system in question.
Authors Rick Kazman, Robert Nord, and Mark Klein from the Ca= rnegie Mellon Software Engineering Institute break down this process from required inputs to outputs. The inputs to the CBAM include a) the system’s business/mission drivers, b) a list of scenarios, and c) the existing architectural documentation. Utilizing these inputs and following the prescribed steps, the CBAM offers outputs that include a) a set of architectural strategies, with associated costs, benefits, and schedule implications, b) prioritized architectural strategies based on Return On Investment, or ROI, and c) the = risk of each architectural strategy, quantified as variability in cost, benefit,= and ROI values (Kazman et al., 2003)<= /a>.
Obviously, the accuracy of the inputs greatly affects the va= lidity of the outputs. For the CBAM to be effective, the previous steps of the SDLC must be correct. Assuming the inputs have merit, the CBAM offers nine steps= for achieving valid outputs. Within these nine steps, various architecture-cent= ered scenarios present themselves for analysis and voting. It is during these st= eps that examination of scenarios occurs for their ability to meet all of the n= eeds of the organization, including business goals, quality attributes, costs, a= nd ROI. These steps repeat themselves until one scenario becomes apparent (Kazman et al., 2003).
The Cost-Benefit Analysis Method described above is an examp= le of several architecture-centric methodologies available in addition to the traditional SDLC. “While each of these steps involves additional over= head as compared with the traditional, non-architecture-aware SDLC, this additio= nal encumbrance is more than repaid by having an architecture that is designed, documented, analyzed, and evolved in a disciplined way” (Kazman et al., 2003).
Many computer-aided tools are available to a programmer when designing an enterprise system following the SDLC. One such tool is Oracle’s Designer/2000. T= his software helps a programmer through the SDLC from start to finish, although Oracle re-designs the SDLC slightly to make the best possible use of their program. Oracle presents this method as CASE Application Development Method= , or CADM (Dorsey & Koletzke, 2000). M= any of the CADM phases are concurrent with the traditional SDLC however; Oracle of= fers Pre-Analysis and Pre-Design Phases to their method.
The Pre-Design Phase= sits between the Analysis and Design Phases. Using Oracle’s CADM, the Pre-Design Phase includes steps for the design plan, process flows, design standards, screen concept prototype, and Pre-Design evaluation. It is during this phase that decisions concerning the screen layout, navigation tools, h= elp systems, documentation, functionality, coding standards, and naming convent= ions come under scrutiny (Dorsey & Koletzke, 2000).
Oracle’s Designer/2000 program aids this process by of= fering templates for the developer to use. “The Pre-Design phase is complete when users are happy with the screen prototypes and process flows. Both use= rs and developers should approve the design standards and Design Plan” (Dorsey & Koletzke, 2000). O= nce complete, the Design Phase begins.
Oracle’s CADM divides the Design Phase into two sub-ph= ases: Database Design and Application Design. Again, this coincides with their Design/2000 software product. “The Design phase is where the blueprints are drawn= for building the system. Every detail should be laid out before generation̶= 1; (Dorsey & Koletzke, 2000). As described in previous paragraphs, good preparation is paramount before actu= al programming begins. Oracle’s Designer/2000 product keeps this in mind= for the programmer and aids both database and application design.
“Database Design involves the designing of the tables = and columns along with the detailed specification of domains and check constrai= nts on the columns” (Dorsey &am= p; Koletzke, 2000). This phase corresponds with the Detailed Design phase = of other methodologies. It is during this phase where the definition of databa= se objects takes place, as well as the tables and modules required of the database. Definition of a final Entity-Relationship Diagram takes place in = this phase, and documentation of the database is an essential deliverable. Again, Oracle’s Designer/2000 program offers templates and menus to aid the developer through this process.
“In addition to the design of specific applications and reports, Application Design involves decision making about what product wil= l be used for those designs, i.e. Visual Basic, Forms, HTML, or C++” (Dorsey & Koletzke, 2000). W= hereas the Database Design determines the underlying database, the Application Des= ign determines how the database will appear before the users. “Another important activity in this part of the Design phase is the cross-checks of = the database design. You want to be sure that the data elements you defined in = the Database Design part of Design are fully utilized and included in the set of modules you produce” (Kazma= n et al., 2003). Once complete and approved, Designer/2000 takes the develop= er to the Build Phase of the CADM.
In this paper, I have examined a methodology and tool availa= ble to developers during the Design Phase of the SDLC. As shown, the SDLC continue= s to evolve and develop as needs and requirements arise. The method and tool examined in this paper represent various methodologies and tools available,= and it becomes incumbent on system developers to prepare themselves with the be= st methodologies and tools for the system.
References
(2005). Cost Benefit Analysis Method (CBAM). Retrieved July 8, 2005, fr=
om http://www.sei.cmu.edu/architecture=
/products_services/cbam.html
Dorsey, P., & Koletz= ke, P. (2000). CASE Application Development Method (CADM) Using Designer/2000. Retrieved July 8, 2005, from http://ourworld.compuserve.com/home= pages/Peter_Koletzke/white_papers/imeth132.pdf
Kazman, R., Nord, R. L.,=
&
Klein, M. (2003, September). A Life=
-Cycle
View of Architectural Analysis and Design Methods. Retrieved July 8, 20=
05,
from http://www.sei.cmu.edu/pub/document=
s/03.reports/pdf/03tn026.pdf
Maryland Department of B= udget & Management (2002, July). Systems Development Life Cycle (SDLC) Volume 2 - SDLC Phases. Retrieved July 8, 2005, from http://docushare.msde.state.md.us/d= ocushare/dsweb/Get/Document-50701/sdlcvol2.pdf
Modell, M. E. (2003). System Development Life Cycle - Design= . Retrieved July 8, 2005, from = http://www.dai-sho.com/ddsd/ddsd04.= html
Thompson Course Technolo= gy (n.d.). The Systems Development Life Cycle.= Retrieved July 8, 2005, from http://www.muskalipman.com/VBObject= s/SDLC.pdf
Design Phase 1