Download It


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Case studies will include Enhancements to do with the netDeploy Global 5.5 release, including path flow coverage, test plans and test procedures as well as some release signoff examples. nDG work that is currently being undertaken for our Minnow project and design improvements in the distribution performance job queue. There is also some examples of the OpenUI source control structure and our use of the revision control system logs.
  • So, you may remember if you paid any attention to what I said last week or didn’t leave early OSA follows an iterative lifecycle for development. This is in effect a mini-waterfall model for continual development of a set of use cases. We apply the workflows as necessary and the end result should be a product we can execute and evaluate. This then provides a feedback mechanism for the next iterative development. Software Engineering process formality varies from one organisation to another. At some organisations it’s just code, code, code. They can be good places to work if there is evidence of process improvement, a willingness to change to follow proper engineering practices. Places where there is no evidence that things will get better or have the ability to improve are the ones that you should move on from. Product development organisations that have processes in place are typically implementing enhancements that are manageable by a single person in a mini-waterfall project. Modeling Models are artifacts used to represent and convey aspects of that reality for a specific purpose. The model is not the reality but the best models are the ones that stick very close to reality. Enough detail. Too little detail leads to chaos and uncertainty. To much detail leads to inconsistency and over-engineering. Models should be refined through successive iterations. You need enough detail to develop from and enough so that someone can review and assess your work and maintain effectively later on.
  • Analyse the problem Identify the problem and needs and specify requirements Develop the problem domain object model Qualify the solution Ensure that your solution will satisfy the needs of the customer by meeting their quality requirements, date and costs. Break up the solution Once the design has been qualified break it up into more manageable parts Remember, Effort is proportional to size. The smaller something is the less complex it is and the easier and quicker it will be to develop. Use your lifecycle to determine when which parts will be delivered to the customer. Control the relationships. This means controlling the relationships between components by ensuring that they are clearly defined and rigorously controlled throughout the development. This means that interface between components are controlled to ensure that they continue to relate to one another in a consistent and predictable manner.
  • In SQA we have four principles/practices that we use to deliver high quality software. Question: Can anyone tell me what they are? Quality Control: Products are developed in conformance to predefined standards. Structure, format, content. Release critieria, Coding Standards & Edicts, Using Templates Configuration Management: Control and documentation of change to development products. Configuration identification, control, auditing. Revision Control (RCS and now CVS), ER and DTS numbers, change management and change impact analysis (no 0 length tasks) Verification and Validation (V&V): Ensure traceability and conformance to requirements. Audits and Reviews. Automated tools. Adherence to standards. Newsgroup review, specific team eviews, one on one review, review processes for walkthroughs, reviews and inspections with formal review guidelines. Single most important technique to improve quality in the product. Traceability to requirements Testing & Evaluation: Functional demonstration and assessment of software product. Satisfies users requirements. Operates in accordance with user’s manual. Operates for a pre-defined time without failure. System can be recovered quickly. System not lacking required parts. White box, black box testing, coverage, review of test results. Question: Testing & evaluation is actually a subset of one of the other 3 principles. Can anyone tell me which one? Delivers product, visibility, traceability and ultimately product integrity. Question: What type of products should we have? Product integrity: fulfils users needs, product can be traced through life cycle. Meets cost expectations and budgets and delivery expectations/deadlines.
  • Not many organisations do business modeling and further more do it well. Just as important is the ability to justify the business case for a project and its implementation lifetime in an organisation. This isn’t generally done.
  • Identifying use cases that aren’t business use cases OSA example of Bruce’s current work BS50 is an example of good work. Do business modeling when need to justify the business case.
  • Example: RS 175 Project Minnow
  • Requirements that aren’t requirements But you should always be thinking about HOW can I do this while developing them. If you’re not sure or don’t know then this is work that will possibly require prototyping. Is that requirement feasible.
  • PDR Excellent mechanism for reviewing the design direction early on. It ensures that for big designs or people with not much experience that they are on track and going in the right direction as canvassed by the team of senior engineers.
  • Use case view Contains a few key scenarios or use cases Logical view Addresses the functional requirements of the system It identifies major design packages, subsystems and classes. Implementation view Describes the organiszation of static software modules (source code, data files, components, executables, and other accompanying artifacts) in the development environment in terms of packaging and layering and in terms of configuration management. Process view Addres the concurrent aspect of the system at run-time - tasks, threads, or processes as well as their interaction. It address issues such as concurrency and parallelism, system startup and shutdown, fault tolerance, and object distribution. It is concerned with scalaiblity. Deployment view Shows how the various executables and other runtime components are mapped to the underlying platforms or computing nodes. It is here that software engineering meets system engineering. It addresses issues such as deployment, installation, and performance. Example: DS163 Distributor Job Batching Design
  • Remember, architecture has this vague definition of “ Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works.” Architecture “ Significant Design decisions.” Architecture encompasses significant decisions about: The organisation of a software system The selection of structural elements and their interfaces by which the system is composed, together with their behaviour as specified in the collaboration among those elements The composition of these elements into progressively larger subsystems The architectural style that guides this organiszation, these elements and their interfaces, their collaborations, and their composition. Architecture is not just concerned about structure and behaviour but also with context: usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and aesthetics. Architecture is a part of design; it is about making decisions about how the system will be built.
  • PFC example
  • Conditions / decisions definition
  • Maintenance of a tree of revisions - RCS is used to maintain a complete history of changes (revisions) to a ‘source’ file. - In addition to the text of each revision, RCS stores the author, date and time of check in, and a log message summarizing the change. - RCS can maintain separate lines of development for each file. It stores a tree structure that represents the ancestral relationships among revisions. Resolution of Access conflicts and merging of revisions and resolution of conflicts - When two or more people try to modify the same revision of a file, RCS alerts them and prevents one modification from corrupting the other. - Two separate lines of development of a file can be coalesced by merging. If the revisions to bemerged affect the same lines of a file, RCS flags the overlapping changes. Release and configuration control - Revisions can be assigned symbolic names or labels. Labels can be used to identify a file revision in relation to product releases, and development milestones. When systematically applied, revision labeling can enable system configuration to be simply accessed and managed.
  • Nightly Build - Several machines do clean full build of the product. - Changes made during the day are picked up. Several types of product are built. They are the p0 product - no tracing, debugging information. It is built for performance. - The p7 build which has path flow coverage information. - The p9 build which contains all our debugging and symbolic information in it. - Some organisations have a very strong culture centered around the build. - Build flag. - OSA build police. Letter of apology. Cause for build breakage and lessons learned. Daily RCS logs - Every code change must be reviewed by at least one other engineer. The name of the reviewer and the enhancement or defect number that implements the change must be included in the RCS log for the change. - Every night a report is generated by collating the RCS logs of all changes made that day. Senior engineers review this to ensure that changes have appropriate descriptions.
  • Test Planning Scope examines what is new to the product, what has changed and what needs to undergo regression testing. Example: nDG5.5 volume testing test plan, reviews limits. Test procedure nDDEPTreeI Test Procedure: Review interface & EC example
  • Alpha - Shipped only to OSA internal staff - Must meet alpha release criteria Beta - Shipped only to nominated customer(s) and their OSA support staff - Must meet Beta release criteria MR - Shipped with new product and/or upgrade sales, and to all customers with a support contract - Must meet MR release critieria Update - An update to a manufacturing release to correct defects - Build from code in a CPE (Customer Product Engineering) branch of the ‘revision tree’. - Shipped with new product and/or upgrade sales, and to all customers with a support contract - Tested as per an MR, with additonal testing to ensure that it can be applied over a particular MR GA (General Availabiltiy) - aka: Gold Release - Concurrent availability of an MR level releases for a product on all of its supported platforms. - Tested as per an MR, for all supported platforms - Shipped with new product and/or upgrade sales, and to all customers with a support contract
  • Example: Release criteria coverage and defect density figures Critical severity defect - The product can’t be used. No work around exists. Data corrupted or lost, system failure or lockup occurs, incorrect answers when necessary for useful operation, program aborts when used correctly, corruption of O/S or system due to incorrect use of product Serious severity defect - The product can’t be used but a work-around exists. Much harder to use than reasonably expected, defect with awkward or inefficient work-around, defect with misleading output, documentation functionality incorrect, program aborts when used incorrectly. Medium severity defect - The product is useable with moderate workaround that can be provided Confusing user interface, program aborts in malicious use, defect is not serious to the operations of the user, inefficient algorithm leads to substantial waster of time/space, defect causes a preferred feature not to be used. Low severity defect - The product is useable with a simple workaround or fix Grammatical error in output, Ugly screen layout, user misunderstanding because of somewhat unclear documentation, cosmetic documentation error where correct use of the product is obvious
  • Example: nDG552 checklist example – overview, development and lab checklist.
  • Prevention: Standards and procedures, audits, defined roles, method of accumulating and disseminating lessons learned from past experience and mistakes. High quality inputs, including software tools and subcontracted software. Appropriately trained and experienced staff Tools that make it difficult or impossible to make common classes of error - design tools check data flows, compilers check for uninitialized variables. Remove the errors in the process that stop the introduction of certain defects or bugs into the process. Audit the work at the project and process level to ensure that the quality of the project work is up to scratch and that the process is still relevant.
  • ISO 9001 and the CMM are provide a framework or a set of requirements for a quality management system. This means they provide the requirements that your quality management system must meet. The design of this system and its subsequent implementation will determine whether we develop a good, that is, usable system or bad, that is not usable with no buy in from engineers. RUP and mentor are processes that organisations have developed and sell to customers for use in their organisation. They detail the workflows, the templates, checklists and in some cases the tools that should be used for adhering to the processes. I think the best approach is the one that Xerox advocates
  • Question: Can anyone tell me what the basic idea is behind this color co-ordinated figure. The basic idea is this: As the benchmark for quality gets higher and the organisation matures we need to plan for continuous improvement, do these plans, check the results and act accordingly. When we have a breakthrough or a successful result we lock in the benefits by making it part of our QA processes - This is supposed to ensure that we consistently meet the levels of quality that the organisation has set.
  • Waiting Occurs when time is not being used effectively. It is an important element of competitiveness and quality. Customers do not appreciate being kept waiting but they may be prepared to pay a premium to be dealt with faster. When operators and employees are waiting for work or simply waiting for something to do, it is waste. A bottleneck operation that is waiting for work is a waste. An hour lost at a bottleneck is an hour lost for the whole plant. Effective use of bottleneck time is a key to regular production which in turn strongly influences productivity and quality. Inappropriate processing Right tool for the job, capable of producing the required quality, distributed to the points of use. Unnecessary actions Importance of ergonomics for quality and productivity. If operators have to unduly exert themselves to perform an activity the operator becomes the victim but quality and productivity is also affected. Transporting Movement of materials is waste. Double handling is a waste that affects productivity and quality. This means monitoring the number of steps or flow lengths through the office. The number of non-value added steps should be monitored. Defects Defects cost money. Overproduction Overproduction is making too much, too early or “just-in-case”. The aim should b to make exactly what is required, no more and no less, just-in-time and with perfect quality. Unnecessary inventory Inventory is the enemy of quality and productivity. Inventory tends to increase leadtime, prevents rapid identification of problems, and increases space thereby discouraging communication. The true cost of extra inventory is very much in excess of the money tied up in it.
  • Example: Requirements Management Brainstorming list Example: Requirements Management Fishbone diagram Training of people - Detailed training plan which includes internal and external training in engineering, quality and management areas.
  • Remember to do good work. It is the key to your success as a software engineer. Resist the temptation to cave into schedule pressures and sacrifice quality. Argue the cost of quality and stick to your guns to do good work. Speak your mind and work for places who value your opinion regardless of whether your right or wrong. Also do have fun, continue to learn new things – make sure your rate of learning is greater then the rate of change - and make new friends. May you never be plagued by the Demons of Stupidity in your workplace.
  • Download It

    1. 1. Project Management & Software Engineering Techniques to Achieve High Software Quality
    2. 2. Introduction <ul><li>What is Quality? </li></ul><ul><li>Project Management Practices </li></ul><ul><li>Software Engineering Practices </li></ul><ul><ul><li>Purpose </li></ul></ul><ul><ul><li>Workflows </li></ul></ul><ul><ul><li>Templates </li></ul></ul><ul><li>Process Improvement Practices </li></ul><ul><li>Review Case Studies to Reveal Techniques </li></ul>
    3. 3. Software Engineering <ul><li>Best Practices </li></ul><ul><li>Business Modeling </li></ul><ul><li>Requirements Analysis </li></ul><ul><li>Design </li></ul><ul><li>Coding & Unit Testing </li></ul><ul><li>Software Testing </li></ul><ul><li>Software Release </li></ul><ul><li>Modeling </li></ul><ul><ul><li>Simplification of reality </li></ul></ul><ul><ul><li>Enough Detail to develop and review effectively </li></ul></ul>
    4. 4. Engineering Best Practices <ul><li>Analyse the Problem </li></ul><ul><li>Qualify the Solution </li></ul><ul><li>Break up the Solution </li></ul><ul><li>Control the Relationships </li></ul>
    5. 5. Quality Assurance Best Practices <ul><li>What are they? </li></ul>Quality Control Configuration Management Validation & Verification Testing & Evaluation Planning Product Visibility Traceability Product Integrity
    6. 6. Business Modeling <ul><li>Purpose: </li></ul><ul><ul><li>Understand Business Domain of an organization </li></ul></ul><ul><ul><ul><li>Identify Business Actors and Business Objects </li></ul></ul></ul><ul><ul><li>Communicate a common understanding to stakeholders </li></ul></ul><ul><ul><li>Derive system requirements </li></ul></ul><ul><ul><li>Justify Business Case </li></ul></ul><ul><ul><ul><li>Decreased Costs </li></ul></ul></ul><ul><ul><ul><li>Increased Revenue </li></ul></ul></ul><ul><li>Workflow </li></ul><ul><ul><li>Find Business Actors and Use Cases </li></ul></ul><ul><ul><li>Develop Business Use Cases </li></ul></ul><ul><ul><li>Review & Update Business Use Cases </li></ul></ul>
    7. 7. Business Modeling <ul><li>Template </li></ul><ul><ul><li>Context and Scope </li></ul></ul><ul><ul><li>Business Use Cases </li></ul></ul><ul><ul><ul><li>Business Use Case Model </li></ul></ul></ul><ul><ul><ul><li>Actors </li></ul></ul></ul><ul><ul><ul><ul><li>Name, Role, Description, Use Case List </li></ul></ul></ul></ul><ul><ul><ul><li>Business Use Cases </li></ul></ul></ul><ul><ul><ul><ul><li>Goal, Main Scenario, Alternate Scenario </li></ul></ul></ul></ul><ul><ul><li>Business Object Model </li></ul></ul><ul><ul><ul><li>Business Workers, Business Entities </li></ul></ul></ul><ul><ul><ul><li>How BUCs are performed in terms of these </li></ul></ul></ul><ul><ul><ul><li>Class represents organisational responsibility </li></ul></ul></ul><ul><ul><li>Supplementary Business Specification </li></ul></ul>
    8. 8. Business Modeling Lessons <ul><li>Identifying Use Cases that aren’t Business Use Cases </li></ul><ul><ul><li>Business Actors are external to business </li></ul></ul><ul><ul><li>BUCs are business processes </li></ul></ul><ul><li>Identifying Business Objects that aren’t Business Objects </li></ul><ul><li>Doing it when not necessary </li></ul><ul><ul><li>Not for all new features </li></ul></ul><ul><ul><li>Do for new projects </li></ul></ul><ul><ul><li>Do when lots of people involved </li></ul></ul><ul><ul><li>Do when lots of information to handle </li></ul></ul><ul><li>Business Justification not being done yet </li></ul>
    9. 9. Requirements Analysis <ul><li>Purpose </li></ul><ul><ul><li>To come to an agreement with the customer and the users on what the system should do </li></ul></ul><ul><ul><li>Basis for estimation and planning the technical contents of iterations </li></ul></ul><ul><ul><li>Define a User Interface for the System </li></ul></ul><ul><li>Classic Definition </li></ul><ul><ul><li>A Requirement is a condition or capability to which a system must conform </li></ul></ul><ul><li>Definition for Use </li></ul><ul><ul><li>WHAT the system does, NOT HOW </li></ul></ul>
    10. 10. Requirements Analysis <ul><li>Workflow </li></ul><ul><ul><li>Requirements Input </li></ul></ul><ul><ul><ul><li>Prototyping </li></ul></ul></ul><ul><ul><ul><li>Business modeling </li></ul></ul></ul><ul><ul><ul><li>Joint application development </li></ul></ul></ul><ul><ul><ul><li>Request for Comment </li></ul></ul></ul><ul><ul><li>Develop Requirements </li></ul></ul><ul><ul><ul><li>Template </li></ul></ul></ul><ul><ul><li>Requirements Review & Update </li></ul></ul><ul><ul><ul><li>Review </li></ul></ul></ul><ul><ul><ul><ul><li>Quality control mechanism </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Requirements under configuration management </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Review checklists </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Appropriate scope, ambiguous, clear, missing requirements </li></ul></ul></ul></ul></ul>
    11. 11. Requirements Analysis <ul><li>Template </li></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><ul><li>Assumptions, Dependencies, Constraints </li></ul></ul></ul><ul><ul><ul><li>Use case diagram </li></ul></ul></ul><ul><ul><li>Use Cases </li></ul></ul><ul><ul><ul><li>Actors </li></ul></ul></ul><ul><ul><ul><li>Scenarios </li></ul></ul></ul><ul><ul><ul><li>Activity Diagrams </li></ul></ul></ul><ul><ul><ul><li>Screen Layouts </li></ul></ul></ul>
    12. 12. Requirements Analysis <ul><li>Template </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><ul><li>Functional </li></ul></ul></ul><ul><ul><ul><li>Usability </li></ul></ul></ul><ul><ul><ul><li>Reliability </li></ul></ul></ul><ul><ul><ul><li>Performance </li></ul></ul></ul><ul><ul><ul><li>Supportability </li></ul></ul></ul><ul><ul><ul><li>Environmental </li></ul></ul></ul><ul><ul><ul><li>Documentation </li></ul></ul></ul><ul><ul><ul><li>Security </li></ul></ul></ul><ul><ul><ul><li>Other </li></ul></ul></ul><ul><ul><li>Consequences </li></ul></ul>
    13. 13. Requirements Analysis <ul><ul><li>Object Modeling </li></ul></ul><ul><ul><ul><li>Attributes </li></ul></ul></ul><ul><ul><ul><li>Responsibilities </li></ul></ul></ul><ul><ul><ul><li>Relationships </li></ul></ul></ul><ul><ul><ul><li>Boundary, Control or Entity </li></ul></ul></ul>
    14. 14. Requirements Analysis Lessons <ul><li>Understand Needs - the Why </li></ul><ul><ul><li>Allows prioritisation </li></ul></ul><ul><ul><li>Allows trade-offs & good design decisions </li></ul></ul><ul><li>Requirements that aren’t requirements </li></ul><ul><ul><li>Propose or lean towards a solution </li></ul></ul><ul><ul><li>Describe the HOW </li></ul></ul>
    15. 15. Requirements Analysis Lessons <ul><li>Use cases </li></ul><ul><ul><li>Over reliance on a main scenario…not enough alternative scenarios </li></ul></ul><ul><ul><li>Weak expression in scenario steps </li></ul></ul><ul><ul><ul><li>Don’t allow steps to become too long or descriptive </li></ul></ul></ul><ul><ul><ul><li>Prefer active voice…a verb is said to be in the active voice if its subject is the agent of the action </li></ul></ul></ul><ul><ul><li>Use activity diagrams when use descriptions become complex and repetitive </li></ul></ul><ul><ul><ul><li>Gives give clear definition of scope and level then use cases </li></ul></ul></ul><ul><ul><li>User Interface Prototypes </li></ul></ul><ul><ul><ul><li>Good visual feedback for user by capturing interactions with system </li></ul></ul></ul><ul><ul><ul><ul><li>Don’t let it become the end of requirements analysis though </li></ul></ul></ul></ul>
    16. 16. Design <ul><li>Purpose </li></ul><ul><ul><li>Translate requirements into a specification that describes how to implement the system </li></ul></ul><ul><ul><li>HOW we do requirement X </li></ul></ul><ul><li>Workflow </li></ul><ul><ul><li>Design Input and Preliminary Design Review </li></ul></ul><ul><ul><ul><li>Prototypes </li></ul></ul></ul><ul><ul><ul><ul><li>Good risk mitigation </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Examines non-functional requirements </li></ul></ul></ul></ul><ul><ul><ul><li>Request for Comment </li></ul></ul></ul><ul><ul><ul><li>PDR </li></ul></ul></ul><ul><ul><ul><ul><li>Good for junior engineers </li></ul></ul></ul></ul>
    17. 17. Design <ul><li>Workflow </li></ul><ul><ul><li>Design Development </li></ul></ul><ul><ul><ul><li>4+1 view of Architecture </li></ul></ul></ul><ul><ul><ul><ul><li>Use cases (+1) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Logical View </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Process View </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Deployment View </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Implementation View </li></ul></ul></ul></ul><ul><ul><ul><li>Detailed Design </li></ul></ul></ul><ul><ul><ul><li>Template </li></ul></ul></ul><ul><ul><li>Design Review </li></ul></ul><ul><ul><ul><li>Quality control mechanism </li></ul></ul></ul><ul><ul><ul><li>Design under configuration management </li></ul></ul></ul><ul><ul><ul><li>Verification of Requirements </li></ul></ul></ul><ul><ul><ul><li>Design Evaluation </li></ul></ul></ul><ul><ul><ul><ul><li>Reuse </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Maintainability </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Reliability </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Performance </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Consistent with Architecture </li></ul></ul></ul></ul>
    18. 18. Design <ul><li>Template </li></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><ul><li>Use Case view </li></ul></ul></ul><ul><ul><ul><li>Logical Object Model </li></ul></ul></ul><ul><ul><ul><li>Process view </li></ul></ul></ul><ul><ul><ul><li>Deployment view </li></ul></ul></ul><ul><ul><ul><li>Implementation view </li></ul></ul></ul><ul><ul><li>Design Assessment </li></ul></ul><ul><ul><ul><li>Design Alternatives </li></ul></ul></ul><ul><ul><ul><li>Maintainability </li></ul></ul></ul><ul><ul><ul><li>Reliability </li></ul></ul></ul><ul><ul><ul><li>Performance </li></ul></ul></ul><ul><li>Architecture and Detailed Design drill down on these at different levels </li></ul>
    19. 19. Design Lessons <ul><li>Object Models </li></ul><ul><ul><li>Finding Objects and Classes that aren’t </li></ul></ul><ul><ul><ul><li>Betrand Meyer “The Grand Mistake” </li></ul></ul></ul><ul><ul><ul><li>“ This class performs…” and Single function classes </li></ul></ul></ul><ul><ul><li>Remember, classes are usually a noun or adjective </li></ul></ul><ul><li>Non-functional requirements </li></ul><ul><ul><li>Design for these, DON’T test them in </li></ul></ul><ul><li>4+1 Architecture </li></ul><ul><ul><li>Only do necessary views </li></ul></ul><ul><ul><li>Architecture that is NOT </li></ul></ul>
    20. 20. Coding & Unit Testing <ul><li>Purpose </li></ul><ul><ul><li>To implement classes and objects in terms of components </li></ul></ul><ul><ul><li>To test the developed components as units </li></ul></ul><ul><ul><li>To integrate into an executable system the results produced by individual implementers or teams </li></ul></ul><ul><li>Workflow </li></ul><ul><ul><li>Code (at last!!!!) </li></ul></ul><ul><ul><li>Code review & unit test </li></ul></ul><ul><ul><ul><li>Which one first </li></ul></ul></ul><ul><ul><ul><li>Quality Control mechanism </li></ul></ul></ul><ul><ul><ul><ul><li>Coding standards </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Path Flow Coverage </li></ul></ul></ul></ul><ul><ul><ul><li>Once reviewed under configuration management </li></ul></ul></ul><ul><ul><ul><li>Verify Design </li></ul></ul></ul><ul><ul><ul><li>Validate requirements </li></ul></ul></ul>
    21. 21. Coding & Unit Testing <ul><li>Template & tools </li></ul><ul><ul><li>C++ & Header templates </li></ul></ul><ul><ul><li>Automated Testing Infrastructure </li></ul></ul><ul><ul><ul><li>Tstlib </li></ul></ul></ul><ul><ul><ul><li>Run nightly </li></ul></ul></ul><ul><ul><ul><li>Results published </li></ul></ul></ul>
    22. 22. Coding & Unit Testing <ul><li>Template & tools </li></ul><ul><ul><li>Path Flow Coverage (PFC) </li></ul></ul><ul><ul><ul><li>White Box Testing </li></ul></ul></ul><ul><ul><ul><li>Unit Testing should result in high PFC </li></ul></ul></ul>
    23. 23. Coding & Unit Testing <ul><li>Template & Tools </li></ul><ul><ul><li>Path Flow Coverage </li></ul></ul>
    24. 24. Coding & Unit Testing <ul><li>Templates & Tools </li></ul><ul><ul><li>Revision Control System (RCS) </li></ul></ul><ul><ul><ul><li>Maintenance of a tree of revisions </li></ul></ul></ul><ul><ul><ul><ul><li>Trunk revisions are on central line </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Branch revisions are to the sides </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Trunk revisions, branches and branch revisions can be labeled symbolically </li></ul></ul></ul></ul><ul><ul><ul><li>Resolution of access conflict and merging of revisions and resolution of conflicts </li></ul></ul></ul><ul><ul><ul><li>Release and configuration control </li></ul></ul></ul>3.0 3.48 4.0 4.12 4.36 ... 3.48.1 4.12.1 4.36.1 trunk d420p6 d420p7 d410 d350 CPE branch CPE branch branch rev. d420 d350p1 d300 d400 Product : OpenUI Development File: windows1.cxx
    25. 25. Coding & Unit Testing <ul><li>Templates & Tools </li></ul><ul><ul><li>Revision Control System (RCS) </li></ul></ul><ul><ul><ul><li>Nightly Builds </li></ul></ul></ul><ul><ul><ul><li>Daily RCS logs </li></ul></ul></ul><ul><li>*** /src/forms/master/src/eqlib/common/fxform.cxx,v *** revision 3.2 date: 1996/04/12 04:25:39; author: shaun; state: Exp; lines: +4 -4 DTS 9001. Previous change wasn't quite correct. Reviewers: pca, agw. =============================================== *** /src/forms/master/src/eqlib/common/text1.cxx,v *** revision 3.33 date: 1996/04/12 06:07:20; author: joeca; state: Exp; lines: +4 -3 DTS9001: added member initialization for copy constructor to stop purify UMR's. Rev michael =============================================== *** /src/forms/master/src/eqlib/common/browser.cxx,v *** revision 1.11.3 date: 1996/04/12 06:09:17; author: michael; state: Exp; lines: +38 -29 DTS14306:Fixed msie i/f to work with dde calls. rev joeca. =============================================== </li></ul>
    26. 26. Coding & Unit Testing Lessons <ul><li>Keep modules small </li></ul><ul><ul><li>Reduces complexity </li></ul></ul><ul><ul><li>Makes code easier to understand </li></ul></ul><ul><li>Develop Unit tests as you code </li></ul><ul><li>Avoid evil hack and slash temptation when you uncover significant design and requirements defects </li></ul>
    27. 27. Software Testing <ul><li>Purpose </li></ul><ul><ul><li>To execute a program with the intent of finding an error </li></ul></ul><ul><ul><ul><li>To Break the Program </li></ul></ul></ul><ul><ul><li>Verify that all requirements have been correctly implemented </li></ul></ul><ul><li>Workflow </li></ul><ul><ul><li>Develop Test Plan & review </li></ul></ul><ul><ul><ul><li>Template </li></ul></ul></ul><ul><ul><ul><li>Review for Team resource plans, test case selection, risk reduction strategies, release criteria applied, conformance to standards, inter team interactions are planned and coordinated </li></ul></ul></ul><ul><ul><li>Develop Test Procedure & review </li></ul></ul><ul><ul><ul><li>Template </li></ul></ul></ul><ul><ul><ul><li>Review for clarify, completeness, usability, reusability, traceability to requirements, satisfies plan, conformance to standards </li></ul></ul></ul>
    28. 28. Software Testing <ul><li>Workflow </li></ul><ul><ul><li>Develop Test Scripts & review </li></ul></ul><ul><ul><ul><li>Template </li></ul></ul></ul><ul><ul><ul><li>Review for satisfaction of test case, test script coding standards </li></ul></ul></ul><ul><ul><ul><li>Testing tools </li></ul></ul></ul><ul><ul><li>Perform Tests </li></ul></ul><ul><ul><ul><li>Forms </li></ul></ul></ul><ul><ul><ul><li>Testing tools </li></ul></ul></ul><ul><ul><li>Summarise and Review Test Results </li></ul></ul><ul><ul><ul><li>Forms </li></ul></ul></ul><ul><ul><ul><li>Review for release readiness </li></ul></ul></ul>
    29. 29. Software Testing <ul><li>Templates & Tools </li></ul><ul><ul><li>Test Planning </li></ul></ul><ul><ul><ul><li>Scope </li></ul></ul></ul><ul><ul><ul><li>Approach </li></ul></ul></ul><ul><ul><ul><li>Environment </li></ul></ul></ul><ul><ul><li>Test Procedure </li></ul></ul><ul><ul><ul><li>Scope </li></ul></ul></ul><ul><ul><ul><li>Test case design </li></ul></ul></ul><ul><ul><ul><ul><li>Equivalence Partitioning </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Limits Testing </li></ul></ul></ul></ul><ul><ul><ul><li>Test cases </li></ul></ul></ul>
    30. 30. Software Testing <ul><li>Templates & Tools </li></ul><ul><ul><li>Test scripts </li></ul></ul><ul><ul><ul><li>Regression suites </li></ul></ul></ul><ul><ul><ul><li>Common Testing Infrastructure Library (CTIL) </li></ul></ul></ul><ul><ul><ul><li>SilkTest </li></ul></ul></ul><ul><ul><li>Perform Tests </li></ul></ul><ul><ul><ul><li>Manual Testing </li></ul></ul></ul><ul><ul><ul><li>Efficiency - Purify & Quantify </li></ul></ul></ul><ul><ul><ul><li>Reliability - Volume Testing & Limits Testing </li></ul></ul></ul><ul><ul><ul><li>Memory Usage Testing </li></ul></ul></ul><ul><ul><ul><li>GUI Testing - Usability </li></ul></ul></ul><ul><ul><li>Test Summaries </li></ul></ul>
    31. 31. Software Testing Lessons <ul><li>Thoroughly inspect the result of each test </li></ul><ul><li>Test cases must be written for the invalid and unexpected (as well as the valid and expected) </li></ul><ul><li>Make test cases and data repeatable </li></ul><ul><li>Do NOT plan a testing effort on the tacit assumption that no errors will be found </li></ul><ul><li>Don’t automate everything </li></ul><ul><ul><li>Automate where there is a benefit </li></ul></ul><ul><li>Apply coding workflows to Test Scripts </li></ul><ul><li>Recognise that Testware is as much a deliverable as software </li></ul>
    32. 32. Software Testing Lessons <ul><li>Regression test suites </li></ul><ul><ul><li>Ensure they are maintained </li></ul></ul><ul><ul><li>Build capability to recover from errors </li></ul></ul><ul><ul><li>Structure tests so that success is not dependent between test cases </li></ul></ul><ul><ul><li>Start each test from a known base state </li></ul></ul>
    33. 33. Software Release <ul><li>Purpose </li></ul><ul><ul><li>To determine if the product is ready for use by our customers by ensuring that all requirements and release criteria have been met </li></ul></ul><ul><li>Workflow </li></ul><ul><ul><li>Product Development Testing is complete and Release Criteria met </li></ul></ul><ul><ul><ul><li>Dependent on release type </li></ul></ul></ul><ul><ul><ul><ul><li>Alpha, Beta, Manufacturing release </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Update, General Availability </li></ul></ul></ul></ul>
    34. 34. Software Release <ul><li>Workflow </li></ul><ul><ul><li>Defect Density severity measures </li></ul></ul><ul><ul><ul><li>Critical </li></ul></ul></ul><ul><ul><ul><li>Serious </li></ul></ul></ul><ul><ul><ul><li>Medium </li></ul></ul></ul><ul><ul><ul><li>Low </li></ul></ul></ul><ul><ul><li>Coverage measures </li></ul></ul><ul><ul><ul><li>For new and modified code </li></ul></ul></ul>
    35. 35. Software Release <ul><li>Workflow </li></ul><ul><ul><li>Customer Care release criteria met </li></ul></ul><ul><ul><ul><li>Customer usability and upgrade impact </li></ul></ul></ul><ul><ul><ul><li>Release notes and documentation usability </li></ul></ul></ul><ul><ul><li>Manufacturing release </li></ul></ul><ul><ul><ul><li>Master source and build CD’s cut </li></ul></ul></ul><ul><ul><ul><li>Master product CD cut </li></ul></ul></ul><ul><ul><ul><li>Escrow cut </li></ul></ul></ul><ul><ul><ul><li>CD autorun </li></ul></ul></ul>
    36. 36. Software Release Checklist <ul><li>Release Checklist </li></ul><ul><ul><li>All stakeholder groups sign-off that release criteria have been met </li></ul></ul><ul><ul><li>Guides developers through the release process </li></ul></ul><ul><ul><li>Records notes about the release </li></ul></ul><ul><ul><li>Identifies: </li></ul></ul><ul><ul><ul><li>Product name </li></ul></ul></ul><ul><ul><ul><li>Package Name and Build Number </li></ul></ul></ul><ul><ul><ul><li>Release Platform/s </li></ul></ul></ul><ul><ul><ul><li>Product Distribution Details </li></ul></ul></ul><ul><ul><ul><li>Product Changes & Defect Fixes </li></ul></ul></ul>
    37. 37. Process Improvement <ul><li>Best Practices </li></ul><ul><li>Standards & Process Frameworks </li></ul><ul><li>Continuous Improvement </li></ul><ul><li>Process for Process Improvement </li></ul>
    38. 38. Process Improvement Best Practices <ul><li>Put effort into Prevention </li></ul><ul><li>Detect and Correct Early </li></ul><ul><li>Eliminate the Cause </li></ul><ul><li>Audit the Work </li></ul><ul><ul><li>Process and Project Level </li></ul></ul>
    39. 39. Standards & Process Frameworks <ul><li>Models </li></ul><ul><ul><li>ISO 9001 </li></ul></ul><ul><ul><li>SEI CMM </li></ul></ul><ul><ul><li>RUP </li></ul></ul><ul><ul><li>Mentor </li></ul></ul><ul><ul><li>Extreme Programming </li></ul></ul><ul><li>Xerox - “Steal from others but Adapt” </li></ul>
    40. 40. Continuous Improvement <ul><li>Wedge and Ball model for continuous improvement </li></ul>Quality Plan Do Check Act QA
    41. 41. Process for Process Improvement <ul><li>Specify Goals of Process </li></ul><ul><ul><li>Simple </li></ul></ul><ul><ul><li>Meet customer and market requirements </li></ul></ul><ul><ul><li>Reduce development time </li></ul></ul><ul><ul><li>Produce high quality products by putting effort into prevention </li></ul></ul><ul><ul><li>Identify & remove wastes </li></ul></ul><ul><ul><ul><li>Waiting </li></ul></ul></ul><ul><ul><ul><li>Inappropriate processing </li></ul></ul></ul><ul><ul><ul><li>Unnecessary actions </li></ul></ul></ul><ul><ul><ul><li>Transporting </li></ul></ul></ul><ul><ul><ul><li>Defects </li></ul></ul></ul><ul><ul><ul><li>Overproduction </li></ul></ul></ul><ul><ul><ul><li>Unnecessary inventory </li></ul></ul></ul>
    42. 42. Process for Process Improvement <ul><li>Identify & prioritise current process issues & select headings </li></ul><ul><ul><li>Brainstorm on issues </li></ul></ul><ul><ul><li>Fishbone diagram (Cause-Effect Diagram) </li></ul></ul><ul><li>Analyse issues & propose solutions to address issues </li></ul><ul><ul><li>Brainstorming </li></ul></ul><ul><ul><li>Why-Why </li></ul></ul><ul><ul><li>How-How </li></ul></ul><ul><li>Define process and review including selection of methods and development standards </li></ul><ul><ul><li>Activity Diagrams </li></ul></ul><ul><li>Develop and review templates and work instructions to support process </li></ul><ul><li>Trial new processes, methods, templates and tools as appropriate </li></ul><ul><li>Training of people </li></ul>
    43. 43. Conclusion <ul><li>Use Software Engineering and Process Improvement techniques to produce high quality software and improve your own personal practices as well as that of your organisation </li></ul>
    44. 44. Closing Remarks <ul><li>Blessing by Patron Saint of Technology, St. Dogbert </li></ul>
    45. 45. Info <ul><li>OSA - http://www. osa ppt /missile. ppt </li></ul><ul><ul><li>ACS Presentation on 4P’s of Short Cycle Product Development </li></ul></ul><ul><li>Rational – </li></ul><ul><ul><li>Unified Software Development Process </li></ul></ul><ul><li>Constantine & Lockwood – http://www. foruse .com/ </li></ul><ul><ul><li>Software for Use </li></ul></ul>