Document

Report
www.mahendar.com
Objectives
1. Identify steps for understanding and solving the
Software Engineering Problems
2. Explain some of the BEST PRACTICES
3. Present the Rational Unified Process within the
context of these BEST PRACTICES
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
www.mahendar.com
The Milestones
•Inception
: Scope
•Elaboration
: Base Line Architecture
•Construction : Build the product
•Transition
: Transit to the end user community
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)
www.mahendar.com
Some Root causes
1.
2.
3.
4.
5.
6.
7.
8.
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
9. Low Intra communication
10.Understanding of Technical risks
11.Gauging Team by the head
www.mahendar.com
The Best Practices
•Develop Iteratively
•Manage requirements
•Use Component based architecture
•Model Visually
•Change management
•Continuously verify Quality
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
www.mahendar.com
Practice 2 : Manage Requirements
The Need :
Software projects failed because :
1. Poor requirement management
2. Incorrect definition of requirements
How to attack :
1. Solve the right problem
2. Build the right solution
www.mahendar.com
How to Achieve Right?
By
Eliciting,
Organizing,
Documenting,
Manage the changing
REQUIREMENTS
www.mahendar.com
Aspects of Requirement Management
1.
2.
3.
4.
5.
6.
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
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
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
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
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
www.mahendar.com
The component architecture yields :
Basis for Re-Use
Basis for Architecture
Basis for Project Management (Planning, Staffing,
Delivery)
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 understanding 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
www.mahendar.com
Practice 5 : Continuously Verify Quality
Test based on the requirements
The ways that a program behaves almost infinite
Inception
Elaboration
Construction
Transition
www.mahendar.com
The dimensions for testing quality
1. Functionality
2. Reliability
3. 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
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
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
www.mahendar.com
Changes to enable Iterative Development
•Secure work spaces for each developer
•Automated integration
•Build Management
•Parallel development
Common problems :
1.
2.
3.
4.
Simultaneous update
Limited notification (All users are not notified)
Multiple update
Multiple versions
www.mahendar.com
Aspects of Change Management System :
1.
2.
3.
4.
5.
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
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

similar documents