Identify steps for understanding and solving the www.mahendar.com Objectives Identify steps for understanding and solving the Software Engineering Problems Explain some of the BEST PRACTICES Present the Rational Unified Process within the context of these BEST PRACTICES

Inception Elaboration Construction Transition www.mahendar.com Rational Unified Process is Architecture centric, use-case centric, Process driven modeling the abstraction of the system It is a team-based definition of the process Its process structure : Inception Elaboration Construction Transition

Elaboration : Base Line Architecture Construction : Build the product www.mahendar.com The Milestones Inception : Scope Elaboration : Base Line Architecture Construction : Build the product Transition : Transit to the end user community

Symptoms in Software Development Process www.mahendar.com Symptoms in Software Development Process User needs not met Requirements turn violently User is not clear …. What he needs Modules do not fit together Hard to maintain Poor or Compromise quality Big difference in Progress v/s Schedule Build and release (wait)

No clear scope definition Architecture is brittle www.mahendar.com Some Root causes No clear scope definition Architecture is brittle 90% done … 90% has to be done Undetected inconsistency Uncontrolled change Improper estimation of project complexity Incomplete study of requirements Lack of common programming practices and conventions within Low Intra communication Understanding of Technical risks Gauging Team by the head

Use Component based architecture Model Visually Change management www.mahendar.com The Best Practices Develop Iteratively Manage requirements Use Component based architecture Model Visually Change management Continuously verify Quality

Practice 1 : Iterative Development www.mahendar.com Practice 1 : Iterative Development Advantages : Yields a good architecture Iteration gives an executable release Address greater risk with an earliest iteration Test and Integrate continuously Enables early user feedback Project management is easy Short term objectives and milestones Risk assessment is easy Helps to draw a comparison diagram

Practice 2 : Manage Requirements www.mahendar.com Practice 2 : Manage Requirements The Need : Software projects failed because : Poor requirement management Incorrect definition of requirements How to attack : Solve the right problem Build the right solution

How to Achieve Right? By Eliciting, Organizing, Documenting, www.mahendar.com How to Achieve Right? By Eliciting, Organizing, Documenting, Manage the changing REQUIREMENTS

Aspects of Requirement Management www.mahendar.com Aspects of Requirement Management Analyze Understand Define the scope of the system Manage Scope Refine the right system Build the right one The different kinds of requirements Functional Non functional

Assess the process impact of the changing the requirements www.mahendar.com What is Traceability Assess the process impact of the changing the requirements Manage the scope and change Whether the system is doing what it intends to do

Meet the current and future requirements Improve extensibility www.mahendar.com Resiliency Meet the current and future requirements Improve extensibility Enable reuse Encapsulate system dependencies Select from the commercially available components Evolve the existing software incrementally

Practice 3 : Use Component Architecture www.mahendar.com Practice 3 : Use Component Architecture Software architecture is the development product that gives highest returns on investment Architecture Trade of analysis Software architecture

It is part of design. Is is about making decision on www.mahendar.com Architecture It is part of design. Is is about making decision on How the system will be built. But it is not all design It stops at major abstractions and major elements Software system architect is the most important aspect that can be used to control the iterative and Incremental development of the system throughout the life cycle

The component architecture yields : www.mahendar.com The component architecture yields : Basis for Re-Use Basis for Architecture Basis for Project Management (Planning, Staffing, Delivery)

(Mostly adopted by many organizations) www.mahendar.com Practice 4 : Visual Modeling (Mostly adopted by many organizations) Model : It is a simplification of reality Reason for building models is for better under- standing of the system and to comprehend its entirety. We capture the structure and behavior To show how the elements put together Keep design and implementation consistent Hide or expose details Promotes unambiguous communication

Practice 5 : Continuously Verify Quality www.mahendar.com Practice 5 : Continuously Verify Quality Test based on the requirements The ways that a program behaves almost infinite QA Involvement Inception Elaboration Construction Transition

The dimensions for testing quality www.mahendar.com The dimensions for testing quality Functionality Reliability Performance Functionality Testing Create test for each key Use-case instance Assess the system functionality by asking what scenario failed and where? What is the corresponding which is not yet exercised

Automated test script generation to provide the www.mahendar.com Reliability Testing Automated test script generation to provide the broad coverage of application under test. Performance Testing Load testing. Verifying the robustness of the application

Practice 6 : Manage Change www.mahendar.com Practice 6 : Manage Change We cannot stop change from being introduced into Our project, but must control the changes, how And when changes are introduced in to a project Artifacts and who introduce the change between Requirement Release

Changes to enable Iterative Development www.mahendar.com Changes to enable Iterative Development Secure work spaces for each developer Automated integration Build Management Parallel development Common problems : Simultaneous update Limited notification (All users are not notified) Multiple update Multiple versions

Aspects of Change Management System : www.mahendar.com Aspects of Change Management System : Change Request Management (CRM) Configuration Status Reporting (CSR) Configuration Management (CM) Change Tracking (CT) Version Selection (VS) CRM: Cost, schedule and impact changes on existing product CSR: For Accounting CM: Defines configuration building and labeling CT: History and rational of changes VC: Right versions for changes of the system

- Requirements and Change Management Design Review www.mahendar.com Concentrating more on - Project Management - Requirements and Change Management Design Review Bug/Error Tracking system should be followed uniformly across all stages helps in ensuring productivity and a better quality deliverable