1. Identify steps for understanding and solving the
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

2. Inception Elaboration Construction Transition
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

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

4. Symptoms in Software Development Process
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)

5. No clear scope definition Architecture is brittle
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

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

7. Practice 1 : Iterative Development
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

8. Practice 2 : Manage Requirements
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

9. How to Achieve Right? By Eliciting, Organizing, Documenting,
How to Achieve Right? By
Eliciting,
Organizing,
Documenting,
Manage the changing
REQUIREMENTS

10. Aspects of Requirement Management
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

11. Assess the process impact of the changing the requirements
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

12. Meet the current and future requirements Improve extensibility
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

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

14. It is part of design. Is is about making decision on
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

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

16. (Mostly adopted by many organizations)
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

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

18. The dimensions for testing quality
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

19. Automated test script generation to provide the
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

20. Practice 6 : Manage Change
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

21. Changes to enable Iterative Development
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

22. Aspects of Change Management System :
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

23. - Requirements and Change Management Design Review
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