Login | Signup | Support
  • 0
  • ×

    Add as FriendSoftware Engineering in the Real World

    by: Rogers

    Current Rating : Rate It :



    1 : Software Engineering in the Real World Team Based Software Development Paul Gibson Development Operations Manager IBM Software Group Development Laboratory at Hursley
    2 : 2 Objectives Understand some of the issues of real world software development projects. Identify practical responses to these issues.
    3 : 3 Software Project Types Market Product / Solutions (Approx 1/3) Multi-Customer Multiple Supported Versions Conflicting Requirements Bespoke Solution (Approx 2/3) Single Customer Requirements negotiable Personal Requirements understood Team Size
    4 : 4 Software Development Environment The Dream All the time you need Clear and Stable Requirements A clear foundation on which to build Waterfall or Iterative Development Process All the people you need Real Life Market & Customer Time Pressure Changing Requirements Dependencies being developed in parallel Overlapping Development Phases Limited Resources & Conflicting Needs
    5 : 5 You start programming – I’ll find out what they want!
    6 : 6 As Team Size Grows above 15 to 20 Problems arise Control Communication Responses Process & Ownership Organisation & Team Structures Architecture Change Control Code Base Control Progress Tracking
    7 : 7 Control & Communication Issues Decision Making Who has the Authority? Who understands the implications and cost? Who has to implement? Who is accountable? Multiple Teams with Multiple Goals Different Functions (Planning, Design, Develop, Test, Service) Different Locations & Countries Different Companies (Co-operation & Competition) Access to Key Information & Changes to Schedules Requirements & Specifications Architecture & Design Interfaces Project & Dependencies Status
    8 : 8 Need to Agree…. Organisation Style Ownership Aligned Goals Team Responsibilities Project Management Process Communication Processes & Frequency Education & Skills HR Policies Team Building Actions
    9 : 9 Process vs Ownership Objective defined process measurable progress traceability to specs documented work repeatable work organization focused compliance praised High Ceremony Cognitive problem-solving meaningful results relevance to mission peer communication effective work people focused technical insight praised Low Ceremony Bureaucracy vs Chaos From James Bach :
    10 : 10 Organisation & Teams As team size grows optimal structure changes Project > Functional > Matrix > Large Project Direct Line Management for Ownership Functional Organisation for Efficiency Multi-Disciplinary Teams for Decisions Considerations Minimise hand offs Organise for Leaders
    11 : 11 Architecture As team & project size grows optimal architecture changes Small, Simple, Uncontrolled ? Comprehensive, Complex, Controlled Modularity and Encapsulation become vital Rigorous Control of all Interfaces Architecture Board Considerations Effective Communication is essential
    12 : 12 Change Control Must have Short Cycle Time ( Iterative ) Control Specification and Product Growth Database Control of Architecture & Design All deliverable function raised as Design Change Requests Further changes tightly controlled Two Sources of Potential Change Request for Additional Function Implementation or testing uncovers design error (Developer’s “Good Ideas”)
    13 : 13 Change Control Process Formal Request for Change Review by Project Team & Design Team for Cost of Analysis If cost of analysis is acceptable then Cost of Implementation Risk ( Mitigated or Added ) Urgency Strategic Validity Return or Value Customer Impact Request formally Committed, Rejected or Deferred Decision clearly communicated to all
    14 : 14 Codebase Control Challenges Large project may have 30,000 components Individual changes potentially effect many components Single codebase may support multiple releases and multiple platforms in the market Enable Maximum Reuse Components can have multiple owners Multiple Concurrent Development and Service Streams Delivered by Library Control System / Configuration Management
    15 : 15 Library System Requirements Base Feature 1 Feature 2 Feature 3 Fixes required to all streams Multiple Concurrent Feature and Platform Development Merge Features with the Base Features have PreReqs
    16 : 16 Library System Requirements Release 1 Release 2 Release 3 Release 4 Fixes Required by Customers X End of Life Multiple Concurrent Release Support Fixes must be merged back to earlier or later releases if code is not common
    17 : 17 Codebase Control Enforced by Library Management All necessary code changes formally tracked and linked to causes / problems Late & development initiated changes tightly controlled Multiple Ownership Effectively Managed Sources of Potential Change New Requirement Market, Customer, Executive, Development, Test New Understanding from Iterative Implementation Defect Discovered Inspections or Analysis detect error Testing detects error In this feature/component, dependent feature/component/product Field Problem This release or later release
    18 : 18 Codebase Control increases with time Less restrictive in changes during early code development(Trust everyone) Rigorously review of all requests for change in later stages (Trust no-one) Rigorous review for Potential Customer Impact Risk of failure Risk of further injection Workarounds Decide what to fix & what to FIN (Fix in Next)
    19 : 19 Progress Tracking Owned by Project Leader Formal Commitment Tracking Estimation is critical - based on track records Include all functional areas Business, Marketing, Development, Test, Production, Service Monthly risk assessments Earned Value Tracking Rolled up to project level Communicated, Published, Shared Metrics & Process Improvement
    20 : 20 Summary Team Based Development Issues Identified Control Communications Strategies for dealing with the Issues Process & Ownership Organisation & Team Structures Effective Architectures Change Control Code Base Control Progress Tracking
    21 : Any Questions?
    22 : 22 References James Bach – Thought provoking views on S/W Development Erran Carmel - Research on Global Software Teams IEEE Software Engineering Body of Knowledge Software Engineering Institute Software Methods & Tools Orthogonal Defect Classification The BCS Agile Methodologies Extreme Programming

    Presentation Tags

    Copyright © 2019 All rights reserved.