1 / 47

DISTRIBUTED APPLICATION DEVELOPMENT (DAD)

DISTRIBUTED APPLICATION DEVELOPMENT (DAD). Presented By: Syed M. Mujtaba Osama Masood Souban Ahmed. Topics to be discussed. Introduction to DAD How to Measure the Success of Implementation of DAD Strengths and Weaknesses of DAD The Process Flow Stage 1 - Plan Project

corin
Download Presentation

DISTRIBUTED APPLICATION DEVELOPMENT (DAD)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DISTRIBUTED APPLICATION DEVELOPMENT (DAD) • Presented By: • Syed M. Mujtaba • Osama Masood • Souban Ahmed

  2. Topics to be discussed • Introduction to DAD • How to Measure the Success of Implementation of DAD • Strengths and Weaknesses of DAD • The Process Flow • Stage 1 - Plan Project • Stage 2 - Activate Project • Stage 3 - Control Project • Stage 4 - DAD Gather Domain Requirements • Stage 5 - DAD Model Domain Requirements • Stage 6 - DAD Establish Development Strategy • Stage 7 - DAD Business Object Analysis • Stage 8 - DAD Design • Stage 9 - DAD Construction • Stage 10 - DAD Testing • Stage 11 - DAD Deployment • Stage 12 - End Project

  3. INTRODUCTION TO DAD

  4. What is Distributed Application Development? • The Distributed Application Development process encompasses modern design principles and proven practices to facilitate the development task and provide developers with a blueprint for building robust and correct distributed applications • It is a collection of experiences and best practices that have been taken from real-world development engagements, providing development teams with access to shared experiences and a proven, repeatable process

  5. DAD key elements • Distributed Application Development has the following key elements: • Concurrent development of packages and components • Reuse of software components (either built in-house or purchased) • Cyclical and incremental development • Release strategy

  6. Why Use Concurrent Development? • This provides a basis for more rapid development • Smooth transitioning from one stage of a project to the next • Continuous delivery of staged results that are of value in the total solution • Implies iteration with a checkpoint at the conclusion of each stage to validate the quality of stage results • The scope of the next stage is also defined with each checkpoint

  7. Successful Implementation of Distributed Application Development

  8. Factors that measure the success of the implementation of distributed application • Usability • Reusability • Stability • Consistency • Quality

  9. Usability: This includes improving user productivity and satisfaction with the system through easier access to and manipulation of data, consistency in the user interface, and access to data through end user tools • Reusability: This measures the capacity to reuse components developed for the application in other distributed applications with a common interface.

  10. Stability: Distributed technology is becoming more robust but is still relatively immature. Consequently, it is essential that the known weaknesses in this technology be acknowledged, understood, sought out and corrected through the design process to achieve stable applications • Consistency: The single greatest factor contributing to user satisfaction is consistency. Users expect that the same types of actions will occur in the same way each time they encounter them. The challenge is to provide a consistent work environment that ensures consistency across systems and tools

  11. Quality: Quality takes on special meaning in distributed implementations, due to the complexities in distributing and upgrading applications across a network environment. Quality must be built in by applying a robust methodology and testing for quality at each checkpoint in the process

  12. STRENGTHS AND WEAKNESSES OF DAD

  13. STRENGTHS • Graphical presentation to the users • Network distribution of applications • Integration of legacy or heritage applications • Integration of purchased packages and components • Robust application based on real-world business objects • Frameworks and patterns availability to reduce development time • Access to shared business data

  14. WEAKNESSES • Complex or long update transaction cycles • Distributed transaction update • Very large database support on servers

  15. THE PROCESS FLOW

  16. The steps in the Distributed Application Development Include • Stage 1 - Plan Project • Stage 2 - Activate Project • Stage 3 - Control Project • Stage 4 - DAD Gather Domain Requirements • Stage 5 - DAD Model Domain Requirements • Stage 6 - DAD Establish Development Strategy • Stage 7 - DAD Business Object Analysis • Stage 8 - DAD Design • Stage 9 - DAD Construction • Stage 10 - DAD Testing • Stage 11 - DAD Deployment • Stage 12 - End Project

  17. Stage 1 - Plan Project • Objectives: • Determine the project goals and objectives • Define the project scope and approach • Define the major products and results • Understand the project risks, assumptions and constraints • Produce a realistic project plan • Gain consensus for the project plan • Process Flow:

  18. Output: The output from this stage would be the introduction of the project being undertaken, the assumptions regarding it, its scope, the budget, the risks associated and the different types of resources required.

  19. Stage 2 - Activate Project • Objectives: • Initiate the project • Ensure timely availability of resources (e.g., people, skills, facilities, equipment, hardware, software, etc.). • Maintain support for the project throughout its lifetime • Manage expectations when a deliverable has reached a significant state (either completed or not completed by the expected date) • Process Flow:

  20. Output: Output of this stage will be the information about the individuals, materials, equipment, or other resources that participate or are used in the project.

  21. STAGE 3 - CONTROL PROJECT • Objectives: • Ensure that project activities are monitored and problems and issues are identified and resolved quickly • Ensure that high quality products and results are produced on time and within budget • Ensure that all project activities are coordinated internally and externally • Process Flow:

  22. Output: Project results - The summarized project results include recommendations for subsequent action, products produced, other significant results, major decisions taken and the reasons for those decisions. Turned over to the project sponsor or project owner and information about what output is reusable is provided to the development coordination organization.

  23. Stage 4 - DAD Gather Domain Requirements • A domain is a portion of the business which has a cohesive business policy. Examples include insurance claims management, telephone call routing, and bank loan management. • Before beginning, the project team should determine what requirements to gather, how to document those requirements, and when to stop gathering requirements. The team then proceeds to document the business process using workflow methods, finally producing the requirements for the implementation of some part of the domain. • Process Flow:

  24. Outputs: Requirements Package - The Requirements Package includes the following types of requirements: • Business • Performance • Operational • Security • Usability • Architectural

  25. Stage 5 - DAD Model Domain Requirements • Business Domain Modeling begins with modeling the documented requirements. Create a documentation structure using a data dictionary. The requirements themselves need to be represented using UML models. • There are two views of the models: behavior view and concept view. Each represents a different aspect of the requirements. The concept view describes the structure of the objects underlying the domain. The behavior view describes the dynamics of interaction of the business domain

  26. Process Flow: • Output: Revised Requirements Package

  27. Stage 6 - DAD Establish Development Strategy • In this stage you must decide how to implement the application requirements via a series of successive software increments or releases. If the decision is to build, the distributed application should be implemented in separate software increments, based on segments of the business domain that translate into logical development projects. Make adjustments to the Business Domain Model as needed. • Process Flow:

  28. Output: Release Strategy - A strategy to develop and deploy incremental versions of a distributed application and to install the additional technical facilities needed to support the information requirements. The Release Strategy is a living document that, while it sets the overall direction of development, is updated as more information about the application and the progress of its development is learned from the incrementally developed projects

  29. Stage 7 - DAD Business Object Analysis • Business Object Analysis needs to model all the concepts and the behavior for the selected software increment. The domain model will provide a high-level view of some large-grained objects and possibly of some fine-grained objects. • Analysts will need to define the exact scope of the software increment so that they can carve out the relevant part of the business domain. At the end of this stage you must subdivide the Specification Model into cohesive areas for iterative development and implementation. • The iterations are defined in terms of design areas, or "packages" (UML terminology for a large grouping of classes). • This stage concludes with a review of the preliminary application design for accuracy, completeness, and architectural integrity

  30. Process Flow:

  31. Output: Specification Model - The Specification Model captures all the information about a particular software increment to be built. • The model is a composite of numerous diagrams, textual definitions and specifications, organized into two views, the Concept View and the Behavior View. • The Concept View is composed of the following model elements • Class Diagrams (including object types, relationship types, attribute types) • Package Diagrams • Operation Specifications • Structural Rules • Various business documents describing the business area • The Behavior View is composed of the following model elements • Use case scenarios • Use case diagrams • Activity diagrams • Events • Context diagrams • State transition diagrams • Elementary Process documentation • Elementary Process Step documentation • Collaboration diagrams • Sequence diagrams • Operations • Model invariants

  32. Stage 8 - DAD Design • Design the complete distributed application • The following activities must be conducted • Review the technical architecture • Identify all operations and services for components of the application • If you are using vendor framework architecture, evaluate and select those classes and packages of the framework architecture that you would like to incorporate into your application design. • Gather the details from business users • Design the presentation, business object, persistent object and data access layers of the application. • Design the services that support the presentation, business object, persistent object and data access layers of the application. • Design all interfaces to the application. • Review the complete design and obtain the formal approval to proceed

  33. Process Flow:

  34. Output: Approved System Design - The full design specification of the distributed application which has passed the Critical Design Review and is ready to be constructed. See the Design task "Perform Critical Design Review" for a list of criteria which the design specification must meet.

  35. Stage 9 - DAD Construction • Develop a construction plan. • Code and build all structures and components of the application, according to a Construction Plan. • Testing at the individual component and integrated component group levels must take place in parallel with the construction of the components. • Process Flow:

  36. Output: Constructed System - The fully constructed distributed application system, ready for system testing. All components have been built, individually tested, and tested within their respective component integration groups.

  37. Stage 10 - DAD Testing • Testing is performed to ensure that the customer receives a high-quality product. • Testing is conducted iteratively in conjunction with the repeat of design and construction activities to fix discrepancies. • When test results indicate that the system needs revision, you must revisit the necessary design and construction activities to implement the changes, and then retest the system.  • Types of Product Testing • Component Testing • Component Integration Testing (a.k.a. String Testing) • System Testing • Performance Testing • Usability Testing • Regression Testing • Product Certification Testing • Pilot Testing (conducted during the deployment of the product)

  38. Process Flow: • Output: Certified Application - The distributed application which has been fully tested and formally certified in the environment in which it must run. Certification is a validation that the newly developed application successfully executes when integrated with other applications as necessary in the production environment.

  39. Stage 11 - DAD Deployment • The Deployment stage includes the following activities: • Development of all essential source code documentation, operational documentation and end-user documentation • Development and delivery of end-user and operations/support personnel training • Preparation of production environment for deployment of all application components • Backup of any system components that are being replaced and may need to be accessible in the event of failure of the new system • Automated and manual data conversion • Help Desk activation • Pilot testing of application at designated test sites and subsequent correction of problems as necessary • Full scale deployment of complete application to users • Hand-off of application maintenance responsibility to appropriate personnel

  40. Process Flow: • Output: Production System - The fully constructed, tested system that is ready for pilot testing and deployment to users.

  41. Stage 12 - End Project • The End Stage brings the project to an orderly conclusion and retains its history for the benefit of subsequent projects. • End Project tasks archive the project materials, report on the project’s performance, turn over the project results to the owners, and release the project resources for use on other projects. • The production of a deliverable or a result is the prerequisite of End Project. Any of the following events can trigger an instance of tasks in the End Project stage:

  42. Objectives: The objectives of End Project are to: • Formally end the project in a controlled manner • Retain project history in the form of metrics, experiences, and lessons learned as input for future efforts • Gain acceptance of the project results • Process Flow:

  43. Output: Project completion products - The Project Completion Products is a comprehensive collection of products produced by the End Project Stage. It consists of the following products: • Project Results (major product) • Project Completion Report (key product) • Project Resource Release (key product)

  44. REFERENCES

  45. http://www.gantthead.com/content/processes/8615.cfm#Process%20Flowhttp://www.gantthead.com/content/processes/8615.cfm#Process%20Flow • http://www.microsoft.com/learning/en/us/syllabi/2549afinal.mspx • http://weblogs.asp.net/rhurlbut/archive/2004/02/12/71854.aspx • http://www.e-zest.net/distributed_application.html

  46. THANKYOU

More Related