Service Oriented Unified Process
(SOUP)

Prepared By:
Hazim Alghalayini
Hazim.alghalayini@gmail.com

December 2013
Abstract
Despite recent reports that it has failed, the reality is that Service-Oriented Architecture (SOA)
remains the be...
What is Service Oriented Unified Process (SOUP)
SOUP is a software methodology that takes the best elements from RUP and X...
Service-Oriented Systems Development Life Cycle
A strategic approach to SOA adoption requires an iterative approach to sys...
The SOUP Process Model
SOUP for initial SOA deployment:
An attempt to show how SOUP maps into RUP was carried out by Kunal...
Formulate the vision and the
scope of the system
Define SOA strategy

Accomplish ROI analysis

Create communications plan
...
Use case definition and
realization
Overall architecture definition
and documentation

Use case and use case realization. ...
development process by defining the technology, coding standards and etc. There is a number of
essential activities that s...
Deploy phase: In this phase, you actually deploy your SOA. You roll it out to individual project
teams, who start using th...
SOUP for ongoing SOA projects:
The SOUP methodology can still be useful for projects that are using an SOA that has alread...
Define phase:
In this phase, you build the tie-ins to the SOA project and understand how to leverage the SOA.
You need to ...
Construct phase:
This phase involves more assembly than new development. As more services become available,
each project w...
eXtreme Programming (XP) with SOA Benefits
SOA indeed requires an evolving software development method, since SOA consists...
Outpatient Department Management in AL-Shifa Hospital Case Study

The purpose of this section is to apply the knowledge ac...
Benefits to hospital: This project is also very beneficial for hospital as their resources (beds and
man power) are optimi...
Department Manager iterative development process
Applying the iterative process to our case study, the Patients Managing D...
Patients Management SOUP phases
The activities in each phase primarily focus on addressing a specific set of risks with th...
Transition Phase

and distributed for evaluation.
The implementation and test
activities to support the R1.0
and R2.0 rele...
Figure 7 Patient use case

Concluding the Inception Phase
The Inception Phase for the Patient Management concludes with th...
For each of these scenarios:


We create a use-case realization, which is a sequence or interaction diagram identifying
t...
Patient Management Construction Phase
The Construction Phase addresses logistical risks, that is, completing the remaining...
We are now ready to deploy the solution as a beta release to be evaluated by users and
stakeholders. This takes us to the ...
Conclusion
As SOA is a new software development paradigm and the methodology for successful SOA
implementation is still no...
Appendixes

Use Case Model for Project: (Management Dental Clinic)

-

This is (doctor)Main use case diagram consist of ma...
-

This is (doctor) management patient consist of (add patient –delete patient –update patient – view all
patient) .
The M...
-

This is (doctor) extraction report consist of search patient and print report .
Only the doctor or the secretary can co...
-

This is (Secretary)Main use case diagram consist of manage patient and extraction report.
The system do verify to infor...
-

This (secretary) change login use case is dependency on current password.
The system verify information and change logi...
ID

1

Name

Add New Patient

Description

This Function to add new Patient information after input
login information
And ...
Add new Patient Sequence
ID

2

Name

Search patient sequence

Description

This sequence to search about patient
And then to show his information....
search patient sequence diagram
ID

3

Name

Update patient sequence

Description

This sequence to update patient information

Actors

Doctor or Secretar...
Update sequence diagram
ID

4

Name

view patients sequence

Description

This sequence to view all patients

Actors

Doctor or Secretary or both....
View All patient sequence diagram
ID

3

Name

Change Password patient sequence

Description

This sequence to update patient information

Actors

Doctor or...
Change Password Sequence diagram
ID

3

Name

Delete Patient sequence

Description

This sequence to update patient information

Actors

Doctor or Secretar...
Delete Sequence diagram
Activity Model for Project:(Management Dental Clinic)

Login Activity Diagram
Add new Patient Activity Diagram
Search Patient Activity Diagram
Class Diagram for Project:(Management Dental Clinic)

java class for Project
Service Oriented Unified Process
Upcoming SlideShare
Loading in …5
×

Service Oriented Unified Process

554 views

Published on

Service-Oriented Architecture is an architecture comprising loosely coupled services, ‎described by platform-agnostic interfaces that can be discovered and invoked dynamically. ‎

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
554
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Service Oriented Unified Process

  1. 1. Service Oriented Unified Process (SOUP) Prepared By: Hazim Alghalayini Hazim.alghalayini@gmail.com December 2013
  2. 2. Abstract Despite recent reports that it has failed, the reality is that Service-Oriented Architecture (SOA) remains the best option available for systems integration and leverage of legacy systems. The technologies to implement SOA will certainly evolve to address emerging needs, but its concepts will remain. To address those needs and concerns that SOA is potentially being stretched beyond its limits, a significant and coordinated research program is needed. Introduction Service-Oriented Architecture is an architecture comprising loosely coupled services, described by platform-agnostic interfaces that can be discovered and invoked dynamically. SOA represents a paradigm shift in software engineering, where the key abstraction is that of services, utilized to support rapid and low-cost application development through service composition. While technology and standards, such as Web services, are important to achieve SOA, it has been widely recognized that they are not sufficient on their own loosely coupled refers to defining interfaces such that they are independent of each other’s implementation. In a loosely coupled system, you should be able to swap-out one of the components and replace it with another and cause no effect to the system, SOA projects potentially suffer from one or more of the following problems:  SOA projects are significantly more complex than typical software projects, because they require a larger, cross-functional team along with correspondingly more complex interteam communication and logistics.  SOA is not well defined, and the vision for the final result is often not clear at the project's inception.  SOA can have a very positive impact on an organization, but, on the other hand, SOA development and replacement of legacy systems can be very expensive.  SOA project has a higher risk of failure than other projects. To overcome these problems one of the research priorities in the field of SOA is finding a proper design and development methodology that consider all SOA principles and causes effective and efficient application development of this architecture. Lots of investigations has been carried out to find out which of nowadays popularly used software developing methodologies, such as agile methodologies or RUP,SOUP, suits SOA principles the best, or whether there is a need of a new SOA development methodology.
  3. 3. What is Service Oriented Unified Process (SOUP) SOUP is a software methodology that takes the best elements from RUP and XP. It is targeted specifically at SOA projects that are underway in any organization. The major driving factors of a typical software development project are the application development process, project management, and the technologies used. These are all driven by the specific consultants assigned to the project. A generic software development project has four variables: time, budget, scope, and quality. Compromising on any one variable has an impact on the overall project. Because of changing business needs, scope and quality are the two most difficult factors to manage. Technological complexities can lead to problems with time and budget management, as well. SOA projects are significantly more complex than typical software projects because they require a larger, cross-functional team along with correspondingly more complex inter-team communication and logistics. A SOA can realize great benefits for an organization, but can be costly and time consuming. If the project is not well defined, with a clear vision for the final result from inception, there's a high risk of failure. The key factors that can help a SOA rollout succeed are:  A clearly defined development process  Enhanced lines of communication across project teams that know the business  Clear support and governance policies On the beginning of the SOA project there's a need for some formal software methodology analogous to RUP that addresses all risks of the project. An agile methodology like XP might not be formal enough and the most important drawback of it is the lack of documentation and any up-front design of the system or of its requirements. However, after SOA project is successfully started, continuing to use this formal methodology for SOA support can make the process too complex. SOUP is a six-phase methodology for SOA application development. SOUP phases represent a distinct set of activities and artifacts that are critical to the success of a SOA project. Figure 1 SOUP Process model We can break the use of the SOUP process into two categories.   SOUP for initial SOA deployment SOUP for ongoing SOA management
  4. 4. Service-Oriented Systems Development Life Cycle A strategic approach to SOA adoption requires an iterative approach to systems development and evolution that reflects the strong link between business strategy and development strategy. SOA adoption is not “all or nothing.” As a matter of fact, one of the benefits of SOA adoption is that systems and system components can be deployed gradually. What follows is a proposed development life cycle for service-oriented systems, where each pass through the life cycle corresponds to an iteration in Figure 2. The main differences with other iterative development frameworks, such as the IBM Rational Unified Process (RUP), are an emphasis on activities to establish and analyze the relationship with business goals at the beginning of the cycle, an emphasis on evaluation at the end of the cycle, and the specification/review of business objectives at the end of the cycle so that the requirements for each iteration follow business objectives. Figure 2 Flow Diagram of the Expanded View of the SOA Problem Space and Solution Space
  5. 5. The SOUP Process Model SOUP for initial SOA deployment: An attempt to show how SOUP maps into RUP was carried out by Kunal Mittal (Mittal, 2010). He made a comparison at a high abstraction level that showed only how SOUP phases map into RUP Figure 3, but he did not performed any deeper analysis, i will make a deeper analysis of how the elements of SOUP methodology maps to RUP Figure 3 SOUP and RUP Model Incept phase: The purpose of this phase is to understand the business needs for SOA adoption and how SOA fits within the organization. The objective of this phase is to decide whether SOA project is profitable by evaluating project scope and risks or not. There is a number of essential activities that should be accomplished and a set of essential artifacts that should be created during the incept phase. These artifacts can be mapped to activities in a following way Activity Artifact Formulate the vision and the SOA vision and scope document which outlines the overall scope of the system vision of the project. It also provides some boundaries that establish the project's scope. Define SOA strategy SOA strategy document which is a high-level plan determining how a project can be implemented: business analysts analyze business requirements of clients, their interactions with suppliers in order to determine the advantages of service-oriented solutions and propose appropriate strategy. Accomplish ROI analysis Return on Investment (ROI) document outlines costs and savings of the project. It should determine short-term and long-term benefits. Create communications plan Communications plan explains how the team of SOA should collaborate with client’s project members and users. Since business stakeholders know organization’s business better than architecture team and business analysts, they can improve processes through participation in service-oriented analysis process. Table 1. Activity Artifact
  6. 6. Formulate the vision and the scope of the system Define SOA strategy Accomplish ROI analysis Create communications plan SOA vision and scope document which outlines the overall vision of the project. It also provides some boundaries that establish the project's scope. SOA strategy document which is a high-level plan determining how a project can be implemented: business analysts analyze business requirements of clients, their interactions with suppliers in order to determine the advantages of service-oriented solutions and propose appropriate strategy. Return on Investment (ROI) document outlines costs and savings of the project. It should determine short-term and long-term benefits. Communications plan explains how the team of SOA should collaborate with client’s project members and users. Since business stakeholders know organization’s business better than architecture team and business analysts, they can improve processes through participation in service-oriented analysis process. Table 1 Incept Phase of SOUP: Activity to Artifact Mapping Define phase: The purpose of this the most critical phase for SOA project is to define the requirements and develop use cases. The objectives of this phase are: 1. To fully understand business processes affected, 2. To collect, define and analyze functional and non-functional requirements by using a formal requirements-gathering and management process like RUP, 3. To design support and governance model which explains how organization will support SOA, 4. To prepare a realistic project plan, 5. To define technical infrastructure that is required to support entire SOA. 6. Creating a project plan with timelines and estimates There is a number of essential activities that should be accomplished and a set of essential artifacts that should be created during the define phase. These artifacts can be mapped to activities in a following way (Table 2). Activity Requirements gathering and analysis Nonfunctional requirements definition and analysis Artifact Functional requirement document: Detailed explanation of all business requirements that SOA will group and cover as business services. Non-functional requirement document. This document describes the requirements including performance considerations, service-level agreements (SLAs), infrastructure requirements, and etc.
  7. 7. Use case definition and realization Overall architecture definition and documentation Use case and use case realization. This document include detailed use cases for all services that will be built. SOA architecture document. This document describes the overall architecture including hardware and software components. SOA applicability document This document explains what projects fall within the scope of the SOA project and how ongoing projects can be built on top of the SOA. Infrastructure definition document. This document includes detailed infrastructure deployment diagrams, outlining the servers, and the connections between them necessary to implement the SOA. Technical infrastructure definition Creating a project plan with timelines and estimates Project plan. This detailed plan for the whole project includes activities, workers, milestones artifacts and dependencies between them. Governance and support model. This is a document which describes how the SOA will be supported and governed also it includes considerations such as SLA monitoring and management. Table 2 Define phase of SOUP: Activity to Artifact Mapping The key deliverables of this phase are:         Functional requirements document Nonfunctional requirements document Use cases and use case realizations SOA architecture document SOA applicability document Infrastructure definition document Project plan Support and governance model The most important deliverable in this stage is the support and governance model. How will the organization support the SOA? What are the governance guidelines? If you roll out a SOA but no one uses it, the project is a failure. The support and governance model document can prevent that from happening. The business should start a project with a realistic set of plans and objectives. Extra requirements should be left for later. An effective business-to-IT (B2IT) collaboration on requirements that can be achieved within the expected time and budget can help ensure success. Design phase: The purpose of design phase is to translate use case realizations and SOA architecture document into detailed design documents. The objectives of this phase are: 1) to create detailed design document and data base model that explain the structure of the services and how they will be built and what database tables and relations will be created, 2) to structure
  8. 8. development process by defining the technology, coding standards and etc. There is a number of essential activities that should be accomplished and a set of essential artifacts that should be created during the design phase. These artifacts can be mapped to activities in a following way (Table 3). Activity Create detailed architecture description with database model To structure the development process Prepare for testing Artifact Detailed design document which explains how services are designed and built Database model. This document includes ERD (Entity Relationship Diagram) of databases used for SOA. Application programming model which includes guidelines on how the development will be structured. It covers such topics as process and technologies being used, coding standards, deployment procedures and so on. Testing and QA plan. This document includes detailed test and quality assurance cases. Table 3 Design Phase of SOUP: Activity to Artifact mapping Construct phase: The purpose of this phase is to construct SOA project. The objectives of this phase are: 1) to iteratively develop, integrate and test SOA, 2) to create user documentation. There is a number of essential activities that should be accomplished and a set of essential artifacts that should be created during the construct phase. These artifacts can be mapped to activities in a following way (Table 4). Activity Iterative development Iterative QA and testing User documentation Artifact Code bases include code files that should be stored in repositories Test results. The results of testing and quality assurance should be stored and kept available for examination. User documentation which was developed in design phase should be kept up-to-date including detailed documentation of code. Table 4 Construct Phase of SOUP: Activity to Artifact Mapping The key deliverables of this phase are:  Code base: The code should be stored in some kind of source control repository.  Test results: The results from the execution of the test cases and QA plans should be available for examination.  Documentation: Documentation should include detailed documentation on the code and any updates to the design documents.
  9. 9. Deploy phase: In this phase, you actually deploy your SOA. You roll it out to individual project teams, who start using the SOA on their projects in a production setting. Perhaps the most obvious key deliverable for this phase is your application in production. However, even more important is the plan that establishes the projects that will pilot the SOA. This leads into the next step of the SOUP methodology, which determines how ongoing projects will use the new architecture. There is a number of essential activities that should be accomplished and a set of essential artifacts that should be created during the deploy phase. These artifacts can be mapped to activities in a following way (Table 5). Activity Create deployment model Create application model Create support model Artifact Deployment model. This document describes the structure of SOA deployment. Application model. This document shows guides for how to use SOA. It becomes important as various project teams begin to use the new architecture. Support Model. This document organizes systematically updates of governance and supports model that was developed in the Define phase. Table 5 Deploy phase of SOUP: Activity to Artifact Mapping The other key deliverables of this phase are:    Deployment model Usage model Ongoing support levels model Support phase: The purpose of this phase is to ensure ongoing SOA support. The objectives of this phase are to support SOA by making bug fixes, trainings and new functionality development. There are a number of essential activities that should be accomplished but SOUP does not provide a set of essential artifacts that should be created during the support phase. The list of essential activities is as follows: Maintenance, Bug fixes, Training, Continuous project buy-in.
  10. 10. SOUP for ongoing SOA projects: The SOUP methodology can still be useful for projects that are using an SOA that has already been rolled out. In such situations, SOUP draws more heavily on XP for inspiration. Figure 4 Overlaid SOUP and XP processes shows the SOUP and XP processes overlaid on each other. Figure 4 Overlaid SOUP and XP processes What is the key premise here? The value of the SOA project is that it provides a well-defined architecture and firm technology guidelines. You have a framework on which to build your applications as services. The project teams' main tasks are building and consuming services. They are most fit to perform these tasks because they have the necessary business domain knowledge. However, they do not need to worry about the technical architecture or invention of technology, as that is left to the SOA teams. Projects of this type follow the same SOUP guidelines outlined in the last section; however, as you'll see, each phase is significantly reduced. Many of the deliverables I describe in this section are the same as those described previously; when necessary, I explain how they differ from their counterparts in a project where an SOA is built from scratch. Incept phase: When you've got an SOA up and running, there's still development work to be done. You'll no doubt want to build projects that consume existing services or expose new ones. In the Incept phase of such a project, you establish the project's overall scope and vision. The key deliverables of this phase are:  Project vision and scope: This would encompass the scope of an individual project, not the larger SOA initiative.  Project strategy: This document describes the strategy and process for this specific project and explains how it leverages the SOA.  ROI analysis: A detailed cost-benefit analysis for the project is crucial to help make decisions about implementation.
  11. 11. Define phase: In this phase, you build the tie-ins to the SOA project and understand how to leverage the SOA. You need to identify the services that the SOA already makes available and those that still need to be built to meet the goals of your project. This phase of a project's lifecycle involves such activities as:     Requirements gathering Services identification Establishing a project plan with timelines and estimates Test case development The key deliverables of this phase are:       Functional requirements document: This is a typical requirements document for a software project. Use cases and use case realizations: These cover the new business processes being built. SOA applicability document: This outlines how the existing SOA framework applies to this project. Project plan: This detailed plan for the whole project includes milestones and dependencies. Services strategy: This document identifies services that already exist and can be consumed along with new services that can be exposed. Test plan: This plan includes test cases for the new project. The requirements gathering in this phase does not need to follow the formal standards that were followed during SOA rollout. Instead, you can make use of agile requirements gathering involving user stories or Class, Responsibilities, Collaborator (CRC) cards (see Resources for more on these). In line with XP thinking, test cases are built early on in this type of project. Design this phase: Is really quick, because most of the design was completed in the initial SOA rollout. In this phase, you only have to worry about how to use the services, what more needs to be built on top of the existing services, and what new services need to be built. The key deliverables of this phase are:  Detailed design document. This document explains how your design leverages the overall SOA and establishes a design and application programming model.  Database model. This document encapsulates a logical and physical database design for this specific project.
  12. 12. Construct phase: This phase involves more assembly than new development. As more services become available, each project will have more to reuse and less to build. XP's iterative development techniques are ideal at this stage of development. In XP, iterative cycles are theoretically set at two weeks, which should be more than ample time for one development-QA cycle when building a small service or consuming a set of services in an SOA environment. With this iterative approach, an SOA can provide valuable business agility via quick software releases. This phase of a project lifecycle involves such activities as:    Iterative development Iterative QA and testing User documentation The key deliverables of this phase are:  New services: Any new services that are being exposed will be ready by the end of this phase.  Test results: Results from the execution of the test cases should be available to all interested parties.  Documentation: This phase of development should produce detailed code documentation along with any necessary updates to other documents created previously. Deploy phase: In this phase, you either launch an application that consumes several services, or you launch new services. The infrastructure is managed by the SOA team; thus, this process is relatively straightforward. Support In this phase, you are only providing support for your new services. In doing so, you will follow the support guidelines laid down during the original SOA project; thus, individual projects don't need to spend much time developing new support guidelines. Managing the SOA lifecycle I introduced SOUP, a new software methodology for building your SOA and then realizing the benefits of the architecture on individual projects. I’ve taken a very high-level look at how this methodology would work, transitioning from an RUP-like methodology (for initially building an SOA) to an XP-style agile process (for ongoing services rollout). By combining the best qualities of these two processes, you can rely on a unified development scheme that nevertheless provides the flexibility needed to manage different stages of an SOA's lifecycle.
  13. 13. eXtreme Programming (XP) with SOA Benefits SOA indeed requires an evolving software development method, since SOA consists of a highly uncertain environment where constant business, protocol, code, process among other changes are already considered and foreseen. Since XP considers changes after every small and rapid iteration, it allows for quick changes inside the code, providing a flexible coding environment. The instant communication with the costumer is also a great strength for the SOA environment, since business rules and processes are constantly changing and adding up to the original project. Direct communication with the costumer can provide a more accurate description of the business needs and requirements the costumer desires in the project. Another strength of XP inside the developing of a SOA is that the high communication between developers; small teams constantly communicating, well defined roles and pair programming seem to provide large improvements in productivity and in obtaining a successful project. Rational Unified Process (RUP) with SOA Benefits As it was compared previously when comparing SOA development necessities with XP, there is a need for proper documentation to keep track of all the requirements, changes, and possibilities when designing services, or SOA type applications, and this is what RUP provides: a methodology that is mainly focused on initial requirements, modeling and documentation, while also keeping the “agile” software development method's principles. Other than fact of providing an upfront documentation, where states the requirements and the most important areas of development; which are useful to state the situation where the company is, it's best practices, and how to provide a visual connection of all the services. Another big benefit of this methodology is that one of it's practices is that it encourages “component based architectures”. This “components” are the building blocks for services, which means that this.
  14. 14. Outpatient Department Management in AL-Shifa Hospital Case Study The purpose of this section is to apply the knowledge acquired from the previous sections in this report and use it to develop a sample application, a system that will be used as part of a patient management system in healthcare systems in the AL-Shifa hospital. Outpatient department is nowadays present in almost every hospital, it is a very good initiative by hospitals as it is also very beneficial to patient also, OPD allow patients to take treatment by good doctors without being admitting in hospital. OPD optimizes the resources and is an outstanding service for effective health care as patient get treated well without paying any hospital charges for bed and other services, doctor get full support from hospital administration and inner department, they can send patient to surgeon if necessary which are available inside hospital. Patient also need not to stay hospital for days or weeks, they can go to home after the doctor consultation and get proper care at their homes as per doctor advices. For OPD we developed an desktop application for doctors sitting at OPD for knowing the number of patients waiting outside for their turn, so that doctors can arrange their schedule accordingly and if there are many patients waiting outside for treatment they can ask for some more doctor to come to OPD for handling patients from hospital administration, so that every patient can be consulted without overloading a single doctor and patient also do not have to waste time by sitting in queue and waiting for their turn. This software helps patient saving their time by doctor getting the list of patient waiting and by doctor taking appropriate action. This project was developed by developing team consisting of 15 people including project leader, tester and developers. Technology being used was PHP. Software process model used was SOUP. SOUP is a software engineering process used to develop software. Benefits of This Project Benefits to doctor: This project really proved a boon for doctor, they can now well manage their patients within the time limit decided by them, as by knowing the number of patients waiting for their turn. Doctor can decide his schedule accordingly and by knowing the name of patient doctor can manage its time by knowing how much time the patient needs if the patient is a old patient i.e. the patient that comes for regular checkup and if that patient need to refer to a surgeon or to any other department for any test than doctor can send the patient to other department without wasting much of patient’s time in waiting. Doctors get opportunity to tackle different cases which increases their experience and helps in diversifying their practice. Benefits to patients: It was also beneficial for patient as if the queue is long they can ask doctor assistant will their number will come today or not and by seeing the name of patients waiting doctor can give an estimation that after how much time their number will come. This would definitely save patient time. It also saves patient money by providing good infrastructure and services at low cost, saves hospital bed charges and other hospital charges. It also saves patient from visiting to knapsack doctor and ensures patients to be treated from authenticate doctors.
  15. 15. Benefits to hospital: This project is also very beneficial for hospital as their resources (beds and man power) are optimized. Outpatient Department in any hospital is considered to be shop window of the hospital. Now a day, the patients are looking for hassle free and quick services in this fast growing world. This is only possible with optimum utility of the resources through multitasking in a single window system in the OPD for better services. Hospital can earn well using OPD as patient feel easy to go and get treated at OPD at low cost and by good doctors without being admitted to hospital. The application is accessed from both a 3270 terminal interface and a Web-based interface using a commercially available Internet browser as illustrated in (Figure 5). SOAP and Web services are used to expose the CICS-controlled information (Outpatient department functions) as serviceoriented architecture (SOA) service providers, which in turn are accessed using SOA service requestors from a browser. Because the focus of this chapter is on the iterative development process applied to specific functions of the Outpatient department application, much of the details concerning the CICS TS configuration and Web services are omitted. You can find additional information about these topics in Application Development for CICS Web Services, SG24-712600. Figure 5 Patient Management System Architecture overview
  16. 16. Department Manager iterative development process Applying the iterative process to our case study, the Patients Managing Development schedule is divided into eight iterations with each iteration spanning three weeks. Typically spans two to three weeks with the total number of iterations dispersed among the four SOUP phases: Inception, Elaboration, Construction, and Transition. The iteration cycle is the heartbeat of the project and after it has been selected, it remains constant for the duration of the project. Both the iteration cycle and the number of iterations are project dependent with the latter directly relating to the complexity of the project. The Patients Managing iterative development plan has one iteration in the Inception Phase, three iterations in the Elaboration Phase, two iterations in the Construction Phase, and two iterations in the Transition Phase. We assess and mitigate the risks during each iteration with each iteration culminating in a minor milestone for the project and facilitating successful achievement of the phase’s objectives. Table 6 illustrates the patients managing project plan broken down into iterations and phases. It depicts the relationship between the iterations and their respective phase, the relationship of the phases to each other, and the major milestone that marks the conclusion of each phase. Table 6 Patient Management Project Plan
  17. 17. Patients Management SOUP phases The activities in each phase primarily focus on addressing a specific set of risks with the aim of reducing the risks and ensuring that the project is moving forward. The milestones at the end of each phase serve a dual process:  The milestone serves to act as a driving force to attain a specific target by providing development status to our stakeholders, whose decisions are key to moving to the next phase.  The milestones are checkpoints for the project as a whole, because they allow developers and management to track the progress of the work as they complete key points in the project lifecycle. Table 7 further describes these phases in more detail as well as the associated major milestone that concludes the phase. Phase Description Milestone Inception Phase The Inception Phase will develop the patients requirements and establish the business case for the system. The major use cases will be identified and a high level Software Development Plan will be developed. At the end of the Inception Phase, we will decide whether to fund and proceed with the project based upon the business case. The Lifecycle Objectives Milestone at the end of the Inception Phase and marks the Go/No Go decision for the project. Elaboration Phase The Elaboration Phase will refine the requirements and develop a stable architecture. At the completion of the Elaboration Phase, all high risk use cases will have been analyzed and designed. An executable system called an architectural prototype will test the feasibility and performance of the architecture. The Lifecycle Architectural Milestone marks the end of the Elaboration Phase. The major architectural components are in place and stable. Construction Phase During the Construction Phase, the remaining use cases will be analyzed and designed. The Beta release will be developed The Initial Operational Capability Milestone (completion of the beta) marks the end of the Construction Phase.
  18. 18. Transition Phase and distributed for evaluation. The implementation and test activities to support the R1.0 and R2.0 releases will be completed. The Transition Phase will prepare the R1.0 and R2.0 releases for distribution. It provides the required support to ensure a smooth installation. The Product Release Milestone (completion of the R2.0 release) marks the end of the Transition Phase. At this point, all capabilities defined in the Vision document are installed and available for the users. Table 7 Phases and milestones Patients Management Inception Phase The Inception Phase addresses business risks so that we focus on mitigating the risk that the project might be either economically undesirable or technically infeasible. During this phase, it is crucial that we discuss with stakeholders their needs and the problems that our solution is attempting to solve. We scrutinize all aspects of the project as well as identify the major use cases. Identifying the major use cases for a this system, such as the Patient Management, entails getting everyone’s agreement that a client ”patients” needs to be able to the information and ability the doctor to extraction report and change login both are appear after true login. Figure 6 Use Case for a Doctor
  19. 19. Figure 7 Patient use case Concluding the Inception Phase The Inception Phase for the Patient Management concludes with the Lifecycle Objective Milestone, which indicates whether to proceed or abandon the project. At this stage, we propose a single solution that:  Solves the right problem  Is technically feasible  Is economically viable All stakeholders agree on these points prior to taking the project to the next step that is, developing the architecture approach in the Elaboration Phase. If all stakeholders do not agree on these points, a decision to cancel the project is made. This can in fact be a desirable outcome of the Inception Phase, because terminating a project at this stage is the least expensive option of all the phases. Patient Management Elaboration Phase The Elaboration Phase addresses architectural and technical risks. It spans three iterations culminating in a Lifecycle Architectural Milestone, which is an executable architecture. This is a partial implementation of the system to verify that we have a stable architecture to support the significant Functionality, Usability, Reliability, Performance, and Scalability (FURPS) requirements. During this phase, we outline the basic and alternate flows of each use case as well as identify the most critical (important) use cases. For each critical use case, we identify the architecturally significant (most important) scenarios for the Patient Management and use them to create the executable architecture; that is, we design, implement, and test these scenarios. We also document these architectural scenarios in our Software Architecture Document.
  20. 20. For each of these scenarios:  We create a use-case realization, which is a sequence or interaction diagram identifying the components to fulfill the behavior specified by the scenario.  We develop test cases that validate the scenarios so that we know what the desired behavior is. Test cases during the Elaboration Phase focus more on identifying problem areas, such as load testing and performance, rather than validating that the desired behavior is correct. Concluding the Elaboration Phase The Elaboration Phase for the Patient Management concludes with the Lifecycle Architectural Milestone. Our aim at this point is to:    Bring architectural and technical risks under control. Establish and demonstrate a sound architectural foundation. Establish a credible plan for developing the product.
  21. 21. Patient Management Construction Phase The Construction Phase addresses logistical risks, that is, completing the remaining work in the allotted time. It spans two iterations culminating in an Initial Operational Capability Milestone, which is assessing that the product is suitable to be delivered to the users. During this phase, we do most of the work and implement all functionality. The remaining scenarios are detailed, designed, implemented, and tested, following a pattern not unlike that of the Elaboration Phase. Up until this point, our testing has been focused on proving the suitability (Inception) and technical feasibility (Elaboration) of the solution. We switch gears now to concentrate more on testing the user interface of the solution, but we also need to ensure that prior architectural tests continue to work as the new functionality is implemented. Because the number of test cases has now grown, we make use of an automation tool to alleviate the manual testing effort. Because we already have an existing COBOL application for the Replenish function, we employ the Bottom-up-approach. Concluding the Construction Phase The Construction Phase for the Patient Management concludes with the Initial Operational Capability Milestone. Our aim at this point is to:    Ensure that the solution is developed according to the requirements. Ensure that the solution is ready to be delivered to the users and stakeholders. Achieve adequate quality as rapidly as possible.
  22. 22. We are now ready to deploy the solution as a beta release to be evaluated by users and stakeholders. This takes us to the Transition Phase. The following sections outline the Patients Management Construction Phase iteration details, work product deliverables, and the use of different tools to develop the project. Patient Management Transition Phase The Transition Phase addresses solution rollout (delivery) risks and brings these risks under control. It spans two iterations culminating in a Product Release Milestone, which marks the product completion. During this phase, we are mostly concerned about deployment and fixing defects identified in the released product. We decide to deliver the Patient Management as two releases: R1 containing only the 3270 components and R2 containing the Web services components. See the following Table 8. Table 8 Transition Phase iterations Concluding the Transition Phase The Transition Phase for the Patient Management concludes with the Product Release Milestone. Our aim at this point is to:  Deliver the solution to its users.  Achieve user self-sufficiency. Successful deployment of the product indicates that the Product Release Milestone has been achieved. Of course, Product Release milestone assessment is based on the satisfaction of our users and stakeholders.
  23. 23. Conclusion As SOA is a new software development paradigm and the methodology for successful SOA implementation is still not developed, lots of researches are being carried out in this area. The aim of this paper was to compare a popularly used RUP methodology, which has provided a large database of knowledge and best practices from successful developments, and is targeted at objectoriented paradigm solutions to SOUP - a new software development methodology for serviceoriented paradigm. Our research showed that RUP methodology cannot be used to develop SOA applications without any adaptation to service-oriented paradigm. Also, our research showed that SOUP methodology is still only in its first steps and should be revised, tested and improved to assure successful SOA developments. The mapping of SOUP activities to RUP activities, SOUP artifacts to RUP artifacts showed that: 1) there are activities and artifacts that are SOA specific and are out of scope of RUP and this is the main reason why RUP cannot be applied in SOA development without any adaptation, and 2) Some RUP activities like risk management that are essential for successful SOA applications development are not included in SOUP and makes this methodology immature and in need of reconsideration and improvement. References  KRUCHTEN, Philippe. The Rational Unified Process An Introduction, Second Edition, Addison Wesley (2000). ISBN: 0-201-70710-1  Sneed, Harry. “Migrating to Web Services: A Research Framework.” Proceedings of the International Workshop on SOA Maintenance Evolution (SOAM 2007), 11th European Conference on Software Maintenance and Reengineering (CSMR 2007), Amsterdam, the Netherlands, March 20-23, 2007.  T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Upper Saddle River: Prentice Hall PTR, 2005.  T. Erl, SOA Principles of Service Design. Prentice Hall PTR, 2008.  LEWIS, Grace; SMITH, Dennis, SMITH; KONTOGIANNIS, Kostas. A Research Agenda for Service-Oriented Architecture (SOA): Maintenance and Evolution of Service-Oriented Systems, SEI (2010). Prieiga per internet ą: <http://www.sei.cmu.edu/reports/10tn003.pdf >  Masoumeh, Department of IT, Iran Telecommunication, Research Center, Tehran, Iran (2010). Proposed Combined Framework of SOA and RUP. Prieiga per internet ą: <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5534806 >  Service-oriented architecture: A brief introduction (2004) [interaktyvus]. [Žiūrėta 2011 m. kovo 31 d.] Prieiga per internet ą: <http://soaprpc.wordpress.com/2009/05/06/service-orientedarchitecture-a-brief-introduction/>  H. M Shirazi, N. Fareghzadeh, and A. Seyyedi, A combinational approach to service identification in SOA, Journal of Applied Sciences Research 5(10) (2009), 1390-1397.
  24. 24. Appendixes Use Case Model for Project: (Management Dental Clinic) - This is (doctor)Main use case diagram consist of manage patient and extraction report. The system do verify to information that are inputted. extraction report and change login both are appear after true login. (Doctor)Main Use case Diagram
  25. 25. - This is (doctor) management patient consist of (add patient –delete patient –update patient – view all patient) . The Manage Patient Appear if only if the Information login is true only the doctor or secretary can controlling it. Manage Patient Use case Diagram
  26. 26. - This is (doctor) extraction report consist of search patient and print report . Only the doctor or the secretary can controlling it. The Manage Patient Appear if only if the Information login is true. (Doctor)Extraction Report Use case diagram - This (doctor) change login use case is dependency on current password. The system verify information and change login if the inputting is true But if the current password is false the system cannot change password. (doctor)change login use case
  27. 27. - This is (Secretary)Main use case diagram consist of manage patient and extraction report. The system do verify to information that are inputted. extraction report and change login both are appear after true login. (secretary) Main Use case - This is (secretary) extraction report consist of search patient and print report . Only the doctor or the secretary can controlling it. - The Manage Patient Appear if only if the Information login is true (Secretary) Extraction Use case
  28. 28. - This (secretary) change login use case is dependency on current password. The system verify information and change login if the inputting is true But if the current password is false the system cannot change password. (Secretary)Change Login use case Sequence Model for Project:(Management Dental Clinic)
  29. 29. ID 1 Name Add New Patient Description This Function to add new Patient information after input login information And verify if the patient exist in database. Actors Doctor or Secretary or both. Pre-Conditions  Inputs Must input patient information (name , age ,gender,……). Must be Login. Flow of Events Basic Path Alternative Paths 1. After actor login app verify login and then control panel appears. 2. Select manage patient 3. Enter add new patient Alternative flow of events 1: By Update information you can clear all Info and input new Info. Post-Conditions  The system display new form success input [Outputs] Message indicating the success of the operation. Related Screenshots Message indicating the success of the operation.
  30. 30. Add new Patient Sequence
  31. 31. ID 2 Name Search patient sequence Description This sequence to search about patient And then to show his information. Actors Doctor or Secretary or both. PreConditions  Inputs Patient ID Must be Login. Flow of Events Basic Path 1.After actor login app verify login and then control panel appears 2. The user selects search patient and app show search screen 3. The user should enter patient ID and app bring it from storage location PostConditions  Things that are true after the use case ends [Outputs] The actor get patient information elated Screenshots Display success mission.
  32. 32. search patient sequence diagram
  33. 33. ID 3 Name Update patient sequence Description This sequence to update patient information Actors Doctor or Secretary or both. PreConditions   Inputs Patient ID – other way to search. Must be Login. The actor who can do this Flow of Events Basic Path 1.After actor login app verify login and then control panel appears 2. The user selects update patient and app show update screen 3. The actor should update patient info and app replaces old info new PostConditions  Things that are true after the use case ends [Outputs] Message indicating the success of the operation related Screenshots Display message to success mission.
  34. 34. Update sequence diagram
  35. 35. ID 4 Name view patients sequence Description This sequence to view all patients Actors Doctor or Secretary or both. PreConditions   Inputs No inputs Must be Login. The actor who can do this Flow of Events Basic Path 1.After actor login app verify login and then control panel appears 2. The actor selects view patients and app show update screen PostConditions [Outputs]  Things that are true after the use case ends App shows all patients
  36. 36. View All patient sequence diagram
  37. 37. ID 3 Name Change Password patient sequence Description This sequence to update patient information Actors Doctor or Secretary or both. PreConditions   Inputs Patient ID . Must be Login. The actor who can do this Flow of Events Basic Path 1.After actor login app verify login and then control panel appears 2.The user extract report and app extracts reports 3. The user selects update patient and app show update screen 4. The actor should update patient info and app replaces old info new PostConditions  Things that are true after the use case ends [Outputs] Message indicating the success of the operation related Screenshots Display message to success mission.
  38. 38. Change Password Sequence diagram
  39. 39. ID 3 Name Delete Patient sequence Description This sequence to update patient information Actors Doctor or Secretary or both. PreConditions   Inputs Patient ID . Must be Login. The actor who can do this Flow of Events Basic Path 1.After actor login app verify login and then control panel appears 2. The user selects update patient and app show update screen 3. The actor should update patient info and app replaces old info new PostConditions  Things that are true after the use case ends [Outputs] Message indicating the success of the operation related Screenshots Display message to success mission.
  40. 40. Delete Sequence diagram
  41. 41. Activity Model for Project:(Management Dental Clinic) Login Activity Diagram
  42. 42. Add new Patient Activity Diagram
  43. 43. Search Patient Activity Diagram
  44. 44. Class Diagram for Project:(Management Dental Clinic) java class for Project

×