Download It
Upcoming SlideShare
Loading in...5

Download It






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Download It Download It Presentation Transcript

  • Software Project Management (SPM) Lecture 12 Selection Of Appropriate Software Project Approach Dr. Daniel Keret 06/03/10
  • Reading Assignment 06/03/10
    • Quality Software Project Management, R. Futrell, D. Shafer, L. Shafer, Prentice-Hall PTR 2002.
    • Chapter 4
    • Software Project Management, Bob Hughes and Mike Cotterell, McGraw-Hill, 3rd Edition.
    • Chapter 4
  • Selection Of Appropriate Software Project Approach.
    • Process Domains:
      • Consumer
      • Business, Industrial
      • Real Time, Really Timely
      • Scientific
    • Classes of Product Systems
      • New Products, Re-Engineering of Existing Products
      • Component Integration, Heroic Maintenance
    • Software Development Life Cycle Models
      • Agile Programming: Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Rapid Application Development (RAD)
      • Waterfall and V-Process Models
      • Prototyping, Spiral and Incremental Deliveries.
    06/03/10 View slide
  • Software Development Processes
    • Development Processes
      • Project Level: Implementation, Software Installation, Software Acceptance & Support
      • System Level: System Requirement Analysis, System Architectural Design, System Integration, System Qualification Testing
      • Software Level: Software Requirement Analysis, Software Architectural Design, Software Detailed Design, Software Coding & Testing, Software Integration, Software Qualification Testing
    • Reasons for choosing a standard software development process
      • Quality Improvement & Guarantee
      • Cost monitoring
      • Communication Improvement
    06/03/10 View slide
  • Project Characteristic
    • Data/Process Oriented
      • Data: Information Systems, Substantial Database, Relational Model
      • Process: Scientific, Embedded control systems. Object Oriented
      • Hybrid: Both Data & Process Characteristic
    • Product/Application Specific
      • Product: General Tool, Remote Updates/Helpdesk, Well Structures
      • Application Specific: Niche, Sector, Business Knowledge is required. Integration, Open Interfaces
    • Special Characteristics
      • Special Hardware/software requirements
      • Safety Critical Application
      • Specific tool is required (graphics, expert system, etc.)
  • Project Risks that Impacts the Software Development Approach
    • Product Uncertainty
      • Requirements are not well defined/Fully documented
      • The users do not understand what the software system will do ( potential gap between the users requirements and the software detailed design)
      • Undefined workflows and interrelations among sub applications
    • Process Uncertainty
      • Introducing new methods/processes to the project team
      • New Application Building Tools
    • Resource Uncertainty
      • Availability of staff
      • Availability of knowledge/experience
    • Project type risks
      • Availability of funding through the final stage of the project
      • Availability & knowledge level of the users
      • Clear definition of interfaces, conversion & implementation
  • The Waterfall Model Stable Product Definition & Well Known Technical Tools
    • Sequence of activities executed top to bottom.
    • Each activity is validated/tested before moving to the next activity
    • Activities:Feasibility study, users requirements, system analysis, system design, program design, coding, testing, installation, operations & support, maintenance, retirement
    • Strength of the Water fall Model
      • Easy to understand/implement
      • Good project control/milestones/utilization of staff
    • Weaknesses of the Model
      • Does not reflect problem-solving nature of software development (iterations, solution preview, changes)
      • A lot of unknowns until the final stages (quality, budget, schedule, functionality, ease of use, maintainability, etc)
      • All requirements should be known upfront
  • The V-Shaped Model Stable Product Definition & Well Known Technical Tools
    • Emphasis on the Validation and Verification activities
    • Testing/Acceptance tests are designed in parallel to Requirements/Architecture Design. Project Requirements are defines in parallel to Product Operation
    • Strengths:
      • Emphasis on validation/testing/verification processes, including all external and internal deliverables
      • Requirements before design before coding
      • Easy to track, easy to use
    • Weaknesses:
      • No iteration/dynamic changes concept
      • Risks and schedules delays can emerge too late in the life cycle of the project
  • 06/03/10
  • System development models using multiple development phases
    • In most projects the first system build is barely usable: too slow, too big, cumbersome
    • First time development using New Technology/System concept in most of the cases is a throwaway
    • The hardest single part of building a software system is to decide what to build (iterative extraction and refinement of the customer needs)
  • The Incremental Model No upfront funding, Year+ Project, Requirements not totally defined, Short market window implies basic functionality first, New technology, Limited staff availability
    • Constructing a partial implementation of a total system and slowly adding increased functionality/performance
    • Waterfall model in overlapping phases
    • Complete up-front set of requirements implemented in a series of small sub-projects, or general objectives that are refined and implemented in groups
    • The early phases of the project (planning, analysis, design) consider the entire system, prioritize requirements and define the groups to be implemented in a sub-project
    • Strength:
      • Funds can be allocated in parts
      • Early operational delivery that maximize the largest benefits
      • Improve knowledge and “ lessons learned ”
      • Reduce risks, easy to test
      • Small pieces are more manageable, can utilize smaller staff, increase project momentum
  • The Incremental Model (Cont.)
    • Weaknesses:
      • No iterations, difficult to change requirements of prior phases
      • Requires good planning and users cooperation
      • Not fully defined requirements can be uncomfortable to management
      • Costs can increase if the physical and the functional design are not fully structured
  • The Spiral Model Medium to High Risk projects, New technology, Complex requirements, Large projects, Computation intensive system, Requirements are not final, No commitment for full budget
    • Support Management Processes, Risk analysis & management
    • Allow Prototyping and Rapid Development
    • Based on 4 major activities that repeats themselves until the delivery of the product. Each repetition (spiral) increases the activity capacity
      • Determine objectives, alternatives and constrains
      • Evaluate alternatives, Identify and resolve risks (risk analysis and prototyping)
      • Develop next layer of software (simulation, detailed design, code, unit test, integration and acceptance)
      • Plan next phase (from project planning to transition plan, integration and testing to operational and training) and review the last 4 quadrants
    • The inner spirals deals with specifications and design
    • The outers spirals deals with development, implementation, maintenance and integration
  • The Spiral Model (Cont.)
    • Advantages:
      • Rapid prototyping allow the users to see the system earlier
      • Early indication of risks, Go-No-Go decision for each spiral
      • Split large development to phases
      • Flexible design
    • Disadvantages:
      • Too expensive for small, low risk projects
      • Complex Model, No industry experience
      • Good prototyping tools and reuse capabilities are a must
    • Simplified versions were developed to overcome the disadvantages.
  • Samples for Partial Implementations of the Spiral Model 06/03/10
  • 06/03/10
  • The Structured Evolutionary Rapid Prototyping Model
    • Prototyping advantages
      • Learning by doing
      • Improve users involvement, communication, clarifications of requirements and completion of requirements
      • Reduce needs for documentation, maintenance costs
      • Production of expected results
    • Prototyping disadvantages
      • Lack of control, Standards
      • Additional cost
      • Users can misunderstood the role of prototyping
      • Developers and users should be located on the same site
    • Types of prototyping
      • Mocks ups
      • Simulated interaction
      • Partial working prototype (vertical or horizontal)
      • Evolutionary prototyping
  • Structured Evolutionary Rapid Prototyping Model Requirements are unstable, not known upfront, changing rapidly Analysis and design portion of Object Oriented development Proof of concept, In combination with other models for parts of the system New developed systems, Interfaces, Technical high risk systems Short lived systems
    • Requirement Phase – A quick partial implementation of the system
      • Rapid analysis, Database creation, User interface, Functions
    • Prototyping Iterations (until users signs – off that the requirements are met)
    • Production Version – Meet full workload and response time constrains, stress test, tuning
  • Other Agile Models
    • Rapid Application Development (RAD)
      • Users are involved through all the stages of the development
      • Utilize graphic user’s interface development tools
    • Dynamic Systems Development Methods (DSDM)
      • Four major iterative parts: Feasibility, Functional, Design/Build, Implementation
      • MuSCoW prioritization: Must have, Should have, Could have, Won ’ t have
    • Extreme Programming (XP)
      • Code should be developed to meet current requirements
      • Emphasis on testing
      • After each software increment the full set of tests is executed in order to verify that the last phase did not corrupted the previous stages