You are on page 1of 12

A “quote” first Software Development Best Practices

“The software developers when estimate that they are 90% done, but it takes 90% to get the rest of the way to 100% done.” In short, “90% done, 90% still remains.”

Why This Session?
• To provide a modern view of SD process (approach, architecture, modeling etc.). • To investigate problems (symptoms), root causes (diagnosis) and solutions (best practices) in team SD process. • To address the issues related to risks, quality and testing of the software product. • To have a prelude idea for Rational Unified Process (RUP).

Objectives of a Modern SD Process
• Apply an iterative, use-case driven, architecturecentric process to the development of a robust design model. • Apply UML to represent the design model. • Apply the concepts of object orientation: abstraction, encapsulation, inheritance and polymorphism at design and implementation level.

Objectives (Cond..)
• Understand the different views of a software architecture, the key mechanism that are defined in support of that architecture, and the effect of the architecture and the mechanisms on the product design. • Describe some basic design considerations, including the use of the patterns.

Audience and Prerequisites
Audience Software practitioners, Software Engineers, Developers, Analysts, Senior Programmers, Designers, Architects. Prerequisites • Some exposure of Object Technology. • Some software development experience.


• Distribution at large.) • Rapid advancement in technology. During the Development There are many successes During the Development and. • Examine SIX best practices for software development. • There are too many projects underway. Scenario is • There are many software products under use. Release Engineer etc. others are verge of completion and some others are under a middle state.A Broad Perspective Ahead • Explore the symptoms and root causes of software development problems. Situation Analysis • World economies are becoming software dependent (Should we put a big question mark ( ) today. distribution and importance. ? A Challenging Scenario • Team sizes are increasing. • Apply these practices to address the root causes of the problems. • There are many software products under development too. • Applications are expanding in size. There are too many failures too. some of them are at concept level. • Not enough qualified manpower is available. • Business is demanding increased productivity and quality in less time and within budget. 2 . complexity. • Specialization is growing (New Specific Roles such as Performance Engineer & QA. So. Integrator & Tester.

what we should doWe should attack these root causes (diagnosis) so that we are not only in position to get rid off the system. where. e.g.. Late discovery of serious project flaws is only a symptom of larger problems. 3 . • • • • • Root Causes of SD Problems Insufficient requirement management. Brittle architecture. Undetected inconsistencies among requirement. Inability to deal with changing requirements. and implementations. Actually. but also we are in a better position to provide quality to the software in a repeatable and productive manner. Symptoms for SD Problems (Contd. We have to diagnose for the symptom i. Insufficient Automation. Ambiguous & imprecise communications. What happens isTreating symptoms does not treat the disease. when. Late discovery of serious project flaws.) • • • • • Insufficient Testing. Modules that don’t fit together. Root Causes of SD Problems (Contd. Software that’s hard to maintain and/or extend. Uncontrolled change preparation.e. • Unacceptable software performance. Overwhelming complexity. Delayed risk reduction due to waterfall approach.Symptoms for SD Problems • • • • • Inaccurate understanding of end-user needs. • Team members in each other’s way are unable to reconstruct who changed what.) • Poor software quality. • An untrustworthy build-and-release process. designs. Unfortunately. subjective project status assessment for above symptom. Subjective project status assessment. why.

Manage control changes. Model the software visually. Use component architectures. timeliness and profits. Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes Practice 1: Develop Software Iteratively • An initial design is likely to be flawed with respect to its key requirements. • Late-phase discovery of design defects results in costly over-runs and/or project cancellation. Verify quality. The time and money spent implementing a faulty design are not recoverable. Manage requirements properly.SIX Best Practices • • • • • • Develop iteratively. Traditional Waterfall Development Requirement Analysis Design Code & Unit Testing Subsystem Testing System Testing Time 4 . Best Practices of SE (Schematic) Develop Iteratively Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes Expect Outcome Practice 1: Develop Iteratively Develop Iteratively Best practices enable high-performance teams resulting into more successful projects in terms of quality.

an additional increment of the system. -Each iteration includes integration and test. • Initial iterations enable early user feedback. • Testing and integration are continuous. Testing starts earlier. Inconsistencies detected early.Waterfall Development Delays Reduction of Risk R I S K Apply the Waterfall Iteratively to System Increments Iteration 1 R D C Iteration 2 R D C Iteration 3 R D C R D C T1 T2 Waterfall T1 T2 T1 T2 T1 T2 TIME -Earliest iterations address greatest risks. Risk Identified and addressed early. • Progress is measured by assessing implementations. Serious misunderstandings evident early in the life cycle. • Partial implementations can be deployed. -Each iteration produces an executable release. Objective assessment thru testing. TIME Waterfall Development Delays Reduction of Risk R I S K Iterative Iterative Development Characteristics • Critical risks are resolved before making large investments. Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes 5 . Development focuses on critical issues. Waterfall Iteration Iteration Iteration Iteration TIME Problems Addressed by Iterative Development Root Causes • • • • • • • Insufficient requirements Ambiguous communications Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Practice 2: Manage Requirements Develop Iteratively Solutions • • • • • • • Enables and encourages user feedback. • Objective milestones provide short-term focus.

• Record of forward and backward trace of the requirements. Inconsistencies detected early. Objective assessment of functionality and performance. • RM is a systematic approach to Eliciting. • Use of iterative process. Prioritizing. attributes.Practice 2: Manage Requirements • Elicit. organizing and documenting the requirements of the systems and Ensuring the agreement between the client and the development team on the changing requirements. Terms of Agreement The Goal Client System to be built Requirements Trace to Many Project Elements Project Management Design & Implementation Requirements Verification Surrogate Goal Change Management Requirements QA & Test Use Case Model Requirements A proxy for the client Requirement Management Catching Requirements Errors Early • Effective analysis of the problem and elicitation of the user needs.Expect to change during software development. • Evaluate changes and determine their impact. • Track and document tradeoffs and decisions. filtering and tracing the requirements. • Agreement with the clients on the requirements and vice versa. Communications based on the specified requirements. Definitions: Requirements and Their Management • A requirement is a condition or capability to which the system must conform. Problems Addressed by Requirements Management Root Causes • • • • • • • Insufficient requirements Ambiguous communications Overwhelming complexity Subjective assessment Poor testing Undetected inconsistencies Insufficient automation Solutions • • • • • • Disciplined approach to requirement gathering. and tracing with automatic links to the documents. 6 . • Establish a baseline and change control process. organize and document required functionality and constraints. • Model interaction between the user and the system. Requirements are dynamic. Provision of a repository tool for requirements.

) • Comprehensibility • Economical and Technological Constraints and Tradeoffs • Aesthetics • Reuse • • • • Resilient & Component Based Architectures • Good architectures. Behavior as specified in collaborations among those elements. Composition of these structural and behavioral elements into progressively larger subsystems.Based Architectures Develop Iteratively • Model Visually Verify Quality Definition of Software Architecture SA is defined as a collection (or organization) of significant components of software system and it involves decisions like: Selection of the structural elements and their interfaces by which a system is composed off. are resilient and are component based • A resilient architecture enables .Practice 3: Use Component. Architectural style that guides this organization of components.Improved maintainability and extensibility -Clean division of work among teams of developers -Encapsulation of hardware and system dependencies Resilient & Component Based Architectures (Contd...) • A component-based architecture permits -Reuse or customization of existing components -Choice of thousands of commercially available components -Incremental evolution of existing software 7 . Manage Requirements Use Component Architectures • • Control Changes • Issues Concerning Architecture Following issues influence SA structurally and behaviorally: Usage Functionality Performance Resilience Issues Concerning Architecture (Contd. that meet their requirements.

Problems Addressed by Component Architectures Root Causes • Brittle Architectures Practice 4:Visually Model Software Develop Iteratively Solutions • • Component facilitates resilient architectures Reuse of commercially available components and framework is facilitated Modularity enables separation of concerns Components provide a natural basis for configuration management. Visual modeling improves our ability to manage software complexity UML: A Tool for Visual Model The Unified Modeling Language (UML) is a language for • Specifying • Visualizing • Constructing • Documenting the artifacts of a software intensive system. • Use case diagrams are used to illustrate user interaction with the systems. • State diagrams are used to illustrate the behavior. Models Sequence Sequence Diagrams Diagrams State State Diagrams Diagrams Component Component Diagrams Diagrams 8 . • Component diagrams are used to illustrate physical structure of the system. • Class diagrams are used to illustrate logical structure. • • • Overwhelming complexity Uncontrolled change • • • Manage Requirements Use Component Architecture Model Visually Verify Quality Control Changes Insufficient Automation Process 4: Visually Model Software • • • • Capture the structure and behavior of architectures Show how the elements of the system fit together Hide or expose details as appropriate for the task Maintain consistency between a design and its implementation • Promote unambiguous communication. Diagrams are views of a model Activity Activity Diagrams Diagrams Object Object Diagrams Diagrams Collaboration Collaboration Diagrams Diagrams Deployment Deployment Diagrams Diagrams Use-Case Use-Case Diagrams Diagrams Class Class Diagrams Diagrams Diagrams are views of a model A model is a complete description of a system from a particular perspective. Visual modeling tools provide automation for component based design. • Object diagrams are used to illustrate objects and links.

• Activity diagrams are used to illustrate the flow of events in a use case. Unnecessary detail hidden when appropriate. it is likely that architectural or design changes are made via changes to the source code. • Interaction diagrams (collaboration and sequence diagrams) are used to illustrate behavior. Visual Modeling and Iterative Development (Changes to Design) Initial Requirements Risk Targeting Assessment Implementation & Testing Deployment Requirements Analysis & Design Visual Modeling and Iterative Development During implementation and testing within an iteration. Visual Modeling and Iterative Development (Change Assessment) Initial Requirements Risk Targeting Assessment Implementation & Implementation & Testing Testing Deployment Requirements Analysis & Design Problems Addressed by Visual Modeling Root Causes • • • • • • • Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Insufficient automation Practice 5: Verify Software Quality Develop Iteratively Solutions • • • • • • • Use cases and scenarios unambiguously specify behavior.) • Deployment diagrams are used to show the mapping of the software to hardware.Diagrams are views of a model (Contd. Unambiguous designs reveal inconsistencies more readily. Some changes are intentional and others are inadvertent. Models capture software design s unambiguously.. Non-modular or inflexible architectures are exposed. Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes 9 . Application quality starts with good design. Visual modeling tools provide support for UML modeling.

How? Test cases for each scenario implemented Analysis tools and code instrumentation Check performance for each use-case/ scenario implemented Test performance for all use cases under authentic and worstcase load 10 .Practice 5: Verify Software Quality C O S T Software problems are 100 to 1000 times more Costly to find and repair after deployment R Iterative Development Permits Continuous Testing Iteration 1 D C T1 T2 Iteration 2 R D C T1 T2 Iteration 3 R D C T1 T2 TIME Deployment Test Life Cycle Test Test Plan Design Implement Execute Evaluate Test Plan Design Implement Execute Evaluate Development Plan Design Implement Execute Evaluate Testing in an Iterative Environment R E Q’ T Iteration 1 Iteration 2 Iteration 3 Automation Reduces Testing Time and Effort One Manual Test Cycle 13000 Tests 2 Weeks 6 People T E S T Test Suite 1 Test Suite 2 Test Suite 3 Test Automation 13000 Tests 6 Hours 1 Person Run More Tests More Often Dimensions of Software Quality Type Functionality Reliability Application Performance System Performance Why? Does my application do what is required? Does my application leak memory? Does my application respond acceptably? Does my system perform under production load? Problems addressed by Verifying Quality Root Causes • Subjective Assessment • Undetected Consistencies • Poor Testing • Insufficient Automation Solutions • Testing provides objective project status assessment • Objective assessment exposes inconsistencies early • Testing and verification are focused on high risk areas • Defects are found earlier and are less expensive to fix • Automated testing tools provide testing for reliability. functionality and performance.

and one is still under development. • Configuration Management (CM): Defining configuration. Components must be reliable i. • Establish secure workplaces for each developer . Building. • • • • 11 . -Control all software artifacts. Control Changes Support All Other Best Practices • Develop Iteratively • Manage Requirements • Use Component Architectures • Model Visually • Verify Quality • Progress is incremental only if changes to artifacts are controlled. one release is in customer use.e. Three Common Problems • Simultaneous Update: Undesired update by later on the work of the former. • Establish an integration work place.Practice 6: Control Changes to Software Develop Iteratively Practice 6: Control Changes to Software Factors of Multiplicity • • • • • • • Multiple Developers Multiple Teams Multiple Sites Multiple Iterations Multiple Releases Multiple projects Multiple platforms Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes Without explicit control. Three Major Aspects of a Change Management System • Change Request Management (CRM): Cost and schedule impacts of a requested changes to the existing product. To avoid scope creep. • Limited Notification: All team members are not notified about fixing of a problem in shared artifacts. • Measurement: Describing the state of the product in terms type. Concepts of Configuration and Change Management • Decompose the architecture into subsystems and assign responsibility for each subsystem to a team. one is in test. Maintaining Trace-ability between versions. • Establish an enforceable change control mechanism. correct versions of all constituent parts are found. Test are only meaningful if the versions of the items under test are known and the items protected from changes.models. number.Provide isolation from changes made at other work places. rate and severity of the defects found and/ or fixing during the course of development. labeling and collecting versioned artifacts. To assure convergence. • Know which changes appear in what releases. assess the impact of the proposed changes before approval. e. docs etc. • Multiple versions: it is usual to have multiple versions of an artifact in different stages at the same time. Parallel development degrades to chaos.g. code. incrementally control models as designs stabilize. • Release a testes baseline at the completion of each iteration.

and Transition that work on organization along the contents of business modeling. analysis and design. project management and environment.Inception. configuration and change management.Problems Addressed by Controlling Changes Root Causes • • • • • • • Insufficient requirements Ambiguous communications Overwhelming complexity Subjective assessment Undetected inconsistencies • Uncontrolled Change Insufficient Automation • • Best Practices Reinforce Each Other Ensures users involved As requirements evolve Validates Architectural Early Address complexity of design/ Implementation incrementally Measure quality early and often Manage Requirements Use Component Architecture Solutions • • • • Requirement change workflow is defined and repeatable Change requests facilitate clear communications Isolated workspaces reduce interference from parallel work Change rate statistics are good metrics for objectively assessing project status Workspaces contain all artifacts.On Budget . customizable system Develop Iteratively Model Visually Verify Quality Control Changes Evolves baseline incrementally The RUP • The RUP (stands for Rational Unified Process) brings the six best practices together in a form that is suitable for a wide range of projects and organizations. deployment. implementation.On Time . Changes maintained in a robust. test. facilitating consistency Change propagation is controlled. requirements. Summary: Best Practices of Software Develoment The result is software that is . Construction. • It has four major phases.Meets Users Needs 12 . Elaboration.