What is the Rational Unified Process?

It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. development team for the Rational Unified Process are working closely with customers

Effective Deployment of 6 Best Practices

1. Develop software iteratively 2. Manage requirements 3. Use component-based architectures 4. Visually model software 5. Verify software quality 6. Control changes to software Inception Phase During the inception phase, you establish the business case for the system and delimit the project scope. To accomplish this you must identify all external entities with which the system will interact (actors) and define the nature of this interaction at a high-level. vision document: a general vision of the core project's requirements, key features, and main constraints. A A initial use-case model (10% -20%) complete). An initial project glossary (may optionally be partially expressed as a domain model). An initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast. An initial risk assessment. A project plan, showing phases and iterations. A business model, if necessary. One or several prototypes. Elaboration Phase The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. The outcome of the elaboration phase is: A use-case model (at least 80% complete) all use cases and actors have been identified, and most usecase descriptions have been developed. Supplementary requirements capturing the non functional requirements and any requirements that are not associated with a specific use case. A Software Architecture Description. An executable architectural prototype. A revised risk list and a revised business case. A development plan for the overall project, including the coarse-grained project plan, showing iterations and evaluation criteria for each iteration. An updated development case specifying the process to be used. A preliminary user manual (optional).

Construction Phase During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly tested. The construction phase is, in one sense, a manufacturing process where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. Transition Phase The purpose of the transition phase is to transition the software product to the user community. Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed.

Core workflows
six core engineering workflows: 1. Business modeling workflow 2. Requirements workflow 3. Analysis & Design workflow 4. Implementation workflow 5. Test workflow 6. Deployment workflow three core supporting workflows: 1. Project Management workflow 2. Configuration and Change Management workflow 3. Environment workflow Business Modeling To make sure that business person should give proper knowledge about system which will be the input for software development person. Requirements The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customer to agree on that description. A Vision document is created, and stakeholder needs are elicited. Actors are identified, representing the users, and any other system that may interact with the system being developed. Use cases are identified, representing the behavior of the system. Analysis & Design show how the system will be realized in the implementation phase. Prototype is created. Implementation Actual coding was done. To test the developed components as units Test Testing was done Deployment Deploy the product on server. Project Management art of balancing competing objectives, managing risk, and overcoming constraints to deliver, successfully, a product in which meets the needs of both customers (the payers of bills) and the users.

Configuration & Change Management the many people who work on a common project. There may be some conflict due to Simultaneous Update When two or more workers work separately on the same artifact, the last one to make changes destroys the work of the former. Limited Notification When a problem is fixed in artifacts shared by several developers, and some of them are not notified of the change. Environment

What is UML?
The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other nonsoftware systems. Goals of UML The primary goals in the design of the UML were: 1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide a formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts such as collaborations, frameworks, patterns and components. 7. Integrate best practices.

Use Cases Diagrams

A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases.

Class Diagrams
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects

Interaction Diagrams
Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. The two kinds of interaction diagrams are sequence and collaboration diagrams. Sequence diagrams:

Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. the diagrams are read left to right and descending. Collaboration diagrams: They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them.

State Diagrams
State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system.

Activity Diagrams
Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel.

Physical Diagrams
Physical diagrams are used when development of the system is complete. Physical diagrams are used to give descriptions of the physical information about a system. There are two types of physical diagrams: deployment diagrams and component diagrams. Deployment diagrams show the physical relationship between hardware and software in a system. Component diagrams show the software components of a system and how they are related to each other.

4+1 Architectural View Model

Logical view : The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include Class diagram, Communication diagram, Sequence diagram Development view : The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram Process view : The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML Diagrams to represent process view include the Activity diagram Physical view : The physical view depicts the system from a system engineer's point-of-view. It is concerned with the topology of software components on the

physical layer, as well as the physical connections between these components. This view is also known as the deployment view. UML Diagrams used to represent physical view include the Deployment diagram Scenarios : The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. UML Diagram(s) used to represent the scenario view include the Use case diagram

Software Testing Types:

Black box testing Internal system design is not considered in this type of testing. Tests are based on requirements and functionality White box testing This testing is based on knowledge of the internal logic of an applications code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions. Unit testing Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses. Integration testing Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems

Functional testing This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application. System testing Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system. Regression testing Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types. Alpha testing In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing. Beta testing Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

ADC : Accelerated Delivery center To build a global network of facilities, infrastructure, and people that enables: accelerated sales and revenue growth increased profitability improved retention service integration improved technology image and profile

ASE : Advanced Solutions Environment distributed delivery slide number - 7 Resolve complex issues within a short time with a heterogeneous group RESULTS IN - Design better implementable solutions by bringing together all knowledge areas

KM tool for knowledge management for CG

ISO - International Standards Organization Quality Management Systems Assurance National Standards Institutes from 146 member countries Bridges public and private sectors through collaboration on standards Envisions The right software, delivered defect free, on time and on cost, every time CMM Capability Maturity Model assesses the quality and maturity of an organizations development approach and practices

AMSC - Applications Management Service Centers Distributed delivery

The Distributed Delivery Rule Book defines the way of delivering engagements involving the use of a Prime location close to the customer and a remote Back Office facility such as near or off-shore centers.

It explains the mandatory requirements expected from any engagement and the responsibilities and activities necessary to achieve successful delivery in this environment. Supporting the Rule Book are Group-wide standards and regional delivery standards, together with delivery templates referenced throughout.

Integrated Architecture Framework (IAF) is an enterprise architecture framework that covers business, information, information system and technology infrastructure.[1][2] This framework has been developed by Capgemini since the 1990s, from the experience of practicing architects on projects for clients across the group. The first version was released in 1996 and was based on the Zachman Framework and Spewaks ideas about Enterprise Architecture Planning.[3] The Integrated Architecture Framework is:

A comprehensive framework to deliver market-leading solutions Adaptable to the specific needs of an organization Scalable from individual projects to enterprise-wide transformation A recognized architecture method in The Open Groups IT Architecture Certification program (ITAC).[4])

Capability Maturity Model Integration (CMMI) is a process improvement approach whose goal is to help organizations improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization There are five levels 1) 2) 3) 4) 5) Initial Manage Define Quantetievly manage Optimize