Software Project Management (SPM)

Lecture 12
Selection Of Appropriate Software Project Approach

Dr. Daniel Keret

5/1/2013 1

Reading Assignment
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

5/1/2013

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.

5/1/2013 3

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

5/1/2013

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.)
5

5/1/2013

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
5/1/2013 6

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
7

5/1/2013

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
8

5/1/2013

5/1/2013

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)
5/1/2013 10

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 11 5/1/2013

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

5/1/2013

12

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
5/1/2013 13

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.

5/1/2013

14

Samples for Partial Implementations of the Spiral Model

5/1/2013

15

5/1/2013

16

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
17

5/1/2013

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

5/1/2013 18

Other Agile Models

Rapid Application Development (RAD) Users are involved through all the stages of the development Utilize graphic users 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, Wont 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
19

5/1/2013