Business Analysis – Level II SOFTWARE DEVELOPMENT LIFE CYCLE

1. Business Analysis – Level IISOFTWARE DEVELOPMENT LIFE CYCLE

2. CONCEPT: software development life cycle (sdlc)

3. Engineering? “Creation” + “Approach for re-creation” • Approach defines • Who • DoesWhat • Whenand • How PROCESS • “Creation of software” + “Approach for its re-creation” • Approach defines • Who - Role • DoesWhat - Activity • When – Workflowand • How - Guideline SOFTWARE ENGINEERING PROCESS

4. Software Engineering Processes V-Process Traditional Waterfall Process Requirements analysis Design Code and unit test Subsystem integration System test Pitfalls • Define all the requirements before development starts • Customer sees the product only at the end !! • Results in expensive overruns and possible cancellation • Resource loading – a big issue • Changes in requirements – tough to accommodate; unplanned iterations!! • Late discovery of serious project flaws–functionality, performance, etc. • Measures progress by assessing work-products that are poor predictors of time-to-completion • Delays and aggregates integration and testing

5. Software Engineering Processes Requirements Analysis & Design Planning Implementation Initial Planning Iterative Process Management Environment Test Evaluation Each iteration results in an executable release Deployment What? • Based on Barry Boehm’s Spiral Model • Process consists of a sequence of incremental steps, or iterations. • Each iteration has all of the development disciplines (requirements, analysis, design, implementation, etc.) • Each iteration also has a well-defined set of objectives. • Each iteration produces a partial working implementation of the final system. • Successive iteration builds on the work of previous iterations to evolve and refine the system until the final product is complete.

6. Comparison Requirements Analysis & Design Planning Implementation Initial Planning Management Environment Iterative Process Test Evaluation Deployment Traditional Waterfall Process Requirements analysis Design Code and unit test Subsystem integration System test • Legend: • Rx : Requirement for use case x • Dx : Design for use case x • Cx : Coding for use case x • Tx : Testing for use case x

7. Comparison Requirements Analysis & Design Planning Implementation Initial Planning Management Environment Iterative Process Test Evaluation Deployment Architecture problems identified Traditional Waterfall Process Requirements analysis Design Code and unit test Subsystem integration System test Architecture Validation

8. Comparison Requirements Analysis & Design Planning Implementation Initial Planning Management Environment Iterative Process Test Evaluation Deployment Traditional Waterfall Process Requirements analysis Design Code and unit test Subsystem integration System test Testing Test Automation

9. Processes Requirements Analysis & Design Planning Implementation Initial Planning Management Environment Iterative Process Test Evaluation Deployment GREAT PROCESS THEN WHY RUP? • What is it NOT? • Risk based approach!!!

10. CONCEPT: rational unified process (RUP)

11. Rational Unified Process What is RUP? • It is an • Iterative • Use Case Driven • Architecture Centric Software development process • Defines • 9 Disciplines, each with • Detailed Workflow and Activities • Performed by specific Roles • Producing specific Artifacts • 4 Phases, each having ‘n’ iterations • RISK based approach

12. Rational Unified Process RUP Best Practices • Develop Iteratively • Manage Requirements • Use Component Architecture • Model Visually • Continuously Verify Quality • Manage Change

13. Rational Unified Process In an iteration, you walk through all disciplines.

14. CONCEPT: RUP – phases and iterations

15. RUP Phases and Iterations Planned (Business) Decision Points Acceptance or End of Life Scope and Business Case Agreement (Understand the problem) Architectural Baseline (Understand the solution) Product Sufficiently Mature for Customers to Use (Build the solution) Planned (Technical) Visibility Points

16. RUP Phases Inception Elaboration Construction Transition • Inception - What to build, Who wants it, Why do they want it, What value does it provides to them • Elaboration - Address project’s highest risks, Demonstrate technical feasibility • Construction - Build software, Deliver working software to the customer at end of each iteration within construction phase • Transition - Prepare to deploy software, Develop Documentation, Training, Customer support time Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release Lifecycle Objective Milestone

17. CONCEPT: BASICS OF AGILE

18. Agile Manifesto More Valuable Definitely Valuable

19. Guiding Principles behind Agile Manifesto • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale • Business people and developers must work together daily throughout the project • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation • Working software is the primary measure of progress • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely • Continuous attention to technical excellence and good design enhances agility • Simplicity--the art of maximizing the amount of work not done--is essential • The best architectures, requirements, and designs emerge from self-organizing teams • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

20. Where does Agile Fit?

21. CONCEPT: Approach to REQUIREMENTS ENGINEERING

22. ValueREAPER – Requirements Engineering Approach for Predictable and Enhanced Results CONSISTENT PREDICTABLE ITERATIVE ASSESS SCOPE DISCOVER DETAIL PLAN REVIEW TRANSITION • To detail Solution Reqs. • Artifacts: • Pr. Soln. Reqs. Use Cases, UI Design, Bus. Rules, Reports Traceability Matrix • Interfaces: SMEs, IA, DA, PM • To transition Impl. team • Artifacts: Issue Log, Traceability Matrix • Interfaces: PM, IA, DA, SA, TL, Dev, QA • To develop Solution Reqs. • Artifacts: • Pr. SH Reqs., Scope Model, Use Case Model, Domain Model, Traceability Matrix • Interfaces: SMEs, Users, IA, SA, DA, PM • To validate developed solution • Artifacts: Change Request Tracker, Impact Analysis, Acceptance Criteria • Interfaces: SMEs, QA, TL, Dev, PM To understand Business Needs Artifacts: Process Maps, Problem Statement, Prioritized Business Requirements Interfaces: SMEs, EA/SA, PM • To verify & validate Solution Reqs. • Artifacts: Review Log, Sign Off Record • Interfaces: Sponsor, SMEs, PM • To plan the BA Approach • Artifacts: Requirements Management Plan • Interfaces: Sponsor, EA, PM UNDERLYING BA COMPETENCIES

23. ValueREAPER – BABOK V2.0 Alignment CONSISTENT PREDICTABLE ITERATIVE ASSESS SCOPE DISCOVER DETAIL PLAN REVIEW TRANSITION Elicitation Req. Analysis Req. Management and Comm. Elicitation Req. Analysis Req. Management and Comm. Solution Assessment and Validation Enterprise Analysis Elicitation Req. Analysis Req. Management and Comm. • Elicitation • Req. • Analysis • Req. Management and Comm. • Solution Assessment and Validation • Enterprise Analysis • Elicitation • Business Analysis Planning and Monitoring Elicitation Req. Analysis Req. Management and Comm. • Enterprise Analysis • Elicitation • Business Analysis Planning and Monitoring BABOK V2.0 KNOWLEDGE AREAS UNDERLYING BA COMPETENCIES

24. Thank You