The RUP recommends using business use cases for locating purposes which have two qualities:(1) easy to understand and (2) easy for the client to use. The RUP does not clarify how these "use cases" should be analyzed to determine what is in the NIMSAD purview. To identify sections of the business that need to be examined, ETHICS uses a stakeholder method that demonstrates all parties interacting with the system. ETHICS harbors a more "macro-view" in comprehending project priorities.
Step 2: Diagnostic Evaluations
The RUP does not attempt to challenge any requirements which devolve from the client. There is no way to accurately analyze whether total autonomy of the system would provide any productive cost-benefit analysis for the overall organization. ETHICS advises that analysis should be conducted on the current situation to prevent the analyst from developing "tunnel vision" and focusing on the first solution that is presented to them and ignoring others, even if the others are more plausible than the original solution first posited.
Step 3: Outlining the Solution
Once the problem has been identified the appropriate decision makers must determine what the correct process should be and when it should be carried out. In the RUP paradigm the client's expectations are gathered in the requirements stage during the Inception Stage. The basic assumption in RUP is that an information system is the appropriate type of solution and the RUP does not explore alternative approaches. The ETHIC model encourages users to identify implausible expectations and to find simple, more cost effective ways to solve business problems.
Step 4: Defining the Problem
The RUP discusses what specific problems are holding the company back from achieving its goal; this discussion is an imperative step in ascertaining the very nature of the problem. The most common form of this level of analysis is a "Gap" analysis. However, RUP is largely ill-equipped to conduct a GAP analysis because it does not collect any information on process efficiency. ETHICS stresses having information available making problem areas, such a bottlenecks and other log jams, easier to detect, diagnose and treat. Once the organization has identified all the relevant goals, ETHICS recommends including performance measures into the comprehensive system.
Step 5: Creating Hypothetical Situations
This process of constructing hypothetical constructs is commonly referred to within the Elaboration Phase. The RUP emphasizes a robust design which is easily configurable should the client requirements or expectations change. In order to bring clients into the fold ETHICS users would use prototypes to illustrate screens, reports and overall program flow. Prototypes are beneficial for the client given they allow the client the access they need to be at ease with the new configurations while avoiding the full investment typical of newly created software.
Step 6: Conceptual and Logical Design
This stage demonstrates the roles of system users. The RUP recommends splitting the software system into subsets and grouping classes into packages. Segregating these packages is an effective practice because it increases system maintenance and creates component integration. ETHICS stresses and focuses on mapping of behavior to "classes," which occurs in the system design phase. The system is partitioned into these "classes" which usually represent business entities, those responsible for carrying out system activities.
Stage 7: Performing Physical Design
The RUP model employs component and deployment diagrams for the purpose of creating a physical design for the client. The RIP also encourages linking components to development teams to improve development productivity. ETHICS advises that required functions are mapped directly to business entities. Domain objects, under ETHICS, are implemented as persistent objects either in a direct-object orientated database or by making use of a relative wrapper.
Stage 8: Implementing Design
The process of creating a workable, effective and efficient implementation strategy is simplified by RUP. RUP then links the business entities to the implementation systems. It is a vital step that the RUP ensure that all of the client's requirements have been fulfilled. All the RUP components must be tested and de-bugged before the RUP can be unveiled to the client.
ETHICS advises to test for functionality and aims to improve quality control and ensure proper project efficacy. ETHICS is not concerned with specific step-by-step implementation of the software architecture by is more focused on business analysis and architectural design. This adheres to ETHICS more "macro-view" in terms of process development. Additionally, ETHICS is a much broader quality control mechanism when it comes to implementing the software. While RUP takes a more hands on approach to client quality control, ETHICS is more focused on the higher level, thirty thousand foot view regarding the software's implementation and the impact this implementation will have on cost-benefit analysis for the organization. Furthermore, ETHICS concerns itself only with the proper construction of the architecture of the software as opposed to RUP that focuses on linking the appropriate systems with the specific business entities to ensure performance.
Through the analysis of the various components along with similarities and differences between these two software design methodologies. The overarching construct used to discern the differences between these two constructs was the NIMSAD normative analytical framework. Although NIMSAD is a well designed qualitative framework it does not represent the only framework and is not absolute in its truths regarding both RUP and ETHICS. Therefore, there should be further analysis, using different frameworks aside from NIMSAD. However, despite all of its flaws, utilizing NIMSAD will allow any individual or organization to effectively determine if either process is more effective than the other in terms of developing and integrating business software.
Additionally, this analysis broke down the essential components of both RUP and ETHICS in an attempt to ascertain the very core of each of these methodologies. This analysis compared and contrasted the various elements of each methodology in order to set up the logical framework and overall construct that was necessary to effectively contrast both methods. Without this inherent and initial foray into the inner most workings of both RUP and ETHICS the preceding analysis would have been rendered very difficult if not total and complete guess work. Once the prima facie examination of the fundamental principles of each method were laid bare the final comparison could commence.
Through an examination of the 8 steps utilized within the NIMSAD methodological review process, the contrasting features of both RUP and ETHICS could be ascertained. Each of these processes had similarities on the surface; however as the analysis went deeper into the NIMSAD framework it became quite clear that both RUP and ETHICS had become quite divergent in their philosophical approaches and their practical implications. Both methods stressed quality control as their logical conclusion, however they had vast differences in terms of arriving at this logical conclusion. The main theme from this analysis within NIMSAD was that ETHICS and RUP have different operating styles, where RUP is a more hands-on and detailed orientated approach, ETHICS is far more broad and generalized.
Avison, D. & Fitzgerald, G. (2006). Information Systems Development Methodologies, Techniques & Tools, 4th Edition,
Ahamd, SandJochen, K (2008). Welcome to the IBM Rational Unified Process and Certification.Available at http://www.ibmpressbooks.com/articles/article.asp?p=1155863&seqNum=2 [Accessed on 24/10/2010]
Boehm B, (1996). Anchoring the Software Process. IEEE Computer Society Press: USA. Vol 13 (4).
Bob H, Mike C, ( 2006 ). Software Project Management, McGraw-Hill Education, Third Edition .
Formal RUP, (2010). available: http://www.rational.com. Accessed on 20/10/2010.
IBM, (2003). IBM Rational Unified Process (RUP). Available at: http://www-01.ibm.com/software/awdtools/rup/?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-08rupsite. Accessed on 19/10/2010.
IBM Software Group, (2003). Rational Unified Process: A Best Practices Approach. IBM Corporation. Available at: http://www.eecg.toronto.edu/~jacobsen/courses/ece1770/slides/rup.pdf. Accessed on: 8/11/2010.
Kruchten, P. (2003). The Rational Unified Process: An Introduction, 3rd Edition, Dec 10, Addison Wesley Professional.
Peraire C, Edwards M, Fernandes, a, Mancin, E, Carroll K, (2007). The IBM Rational Unified Process for System z: Making Development on System z More Agile. Available at: http://www.ibm.com/developerworks/rational/library/jun07/peraire/index.html#N105C8> Accessed on 27/10/2010
Per Kroll, Kruchten P. (2003). Rational Unified Process Made Easy, the: A Practitioner's Guide to the RUP. Addison-Wesley Professional. 1st edition.
Rational Software (1998). Rational Unified Process: Best Practices for Software Development Teams. Available at: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf. Accessed on 21/10/2010.
Robert F, Donald S, Linda S, (2001), Quality Software Project Management .Prentice Hall PTR Upper Saddle River: USA.
Scott, a (2005). A Manager's Introduction to the Rational Unified Process (RUP).Available at http://www.ambysoft.com/downloads/managersIntroToRUP.pdf [Accessed on 20/10/2010]
Scott JE, Vessey I, (2002). Managing Risks, Communications of the ACM: USA.
Yaghini M, (2009). A Framework for Selection of Information Systems Development Methodologies. CCSE Journal. Vol 2 (1).
WittmannClan, (2005). Software Life-cycles Available at: http://www.wittmannclan.de/ptr/cs/slcycles.html. Accessed on: 21/10/2010.