software project management (spm)-lecture-12

7/30/2019 Software Project Management (SPM)-Lecture-12

1/19

5/1/2013 1

Software Project Management(SPM)

Lecture 12

Selection Of Appropriate

Software Project Approach

Dr. Daniel Keret


2/19

Reading Assignment

5/1/2013 2

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


3/19

5/1/2013 3

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), DynamicSystems Development Method (DSDM), Rapid ApplicationDevelopment (RAD)

Waterfall and V-Process Models

Prototyping, Spiral and Incremental Deliveries.


4/19

5/1/2013 4

Software Development Processes Development Processes

Project Level: Implementation, Software Installation,Software Acceptance & Support

System Level: System Requirement Analysis, SystemArchitectural Design, System Integration, SystemQualification Testing

Software Level: Software Requirement Analysis,Software Architectural Design, Software DetailedDesign, Software Coding & Testing, SoftwareIntegration, Software Qualification Testing

Reasons for choosing a standard software

development process Quality Improvement & Guarantee

Cost monitoring

Communication Improvement


5/19

5/1/2013 5

Project Characteristic Data/Process Oriented

Data: Information Systems, Substantial Database, RelationalModel

Process: Scientific, Embedded control systems. ObjectOriented

Hybrid: Both Data & Process Characteristic

Product/Application Specific

Product: General Tool, Remote Updates/Helpdesk, WellStructures

Application Specific: Niche, Sector, Business Knowledge isrequired. Integration, Open Interfaces

Special Characteristics Special Hardware/software requirements

Safety Critical Application

Specific tool is required (graphics, expert system, etc.)


6/19

5/1/2013 6

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 softwaredetailed 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


7/19

5/1/2013 7

The Waterfall ModelStable Product Definition & Well Known Technical Tools

Sequence of activities executed top to bottom.

Each activity is validated/tested before moving to the nextactivity

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


8/19

5/1/2013 8

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


9/19

5/1/2013 9


10/19

5/1/2013 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 NewTechnology/System concept in most of thecases is a throwaway

The hardest single part of building a software

system is to decide what to build (iterativeextraction and refinement of the customerneeds)


11/19

5/1/2013 11

The Incremental ModelNo 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 andslowly adding increased functionality/performance

Waterfall model in overlapping phases

Complete up-front set of requirements implemented in a seriesof 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 definethe 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


12/19

5/1/2013 12

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


13/19

5/1/2013 13

The Spiral ModelMedium 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 deliveryof the product. Each repetition (spiral) increases the activity capacity

Determine objectives, alternatives and constrains

Evaluate alternatives, Identify and resolve risks (risk analysis andprototyping)

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 thelast 4 quadrants

The inner spirals deals with specifications and design

The outers spirals deals with development, implementation,maintenance and integration


14/19

5/1/2013 14

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.


15/19

5/1/2013 15

Samples for Partial Implementations of the Spiral Model


16/19

5/1/2013 16

Th St t d E l ti


17/19

5/1/2013 17

The Structured Evolutionary

Rapid Prototyping Model Prototyping advantages

Learning by doing

Improve users involvement, communication, clarifications ofrequirements 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

S d E l i R id P i M d l


18/19

5/1/2013 18

Structured Evolutionary Rapid Prototyping ModelRequirements 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 systemsShort lived systems

Requirement PhaseA quick partial

implementation of the system

Rapid analysis, Database creation, User interface,Functions

Prototyping Iterations (until users signsoff

that the requirements are met)

Production VersionMeet full workload and

response time constrains, stress test, tuning


19/19

5/1/2013 19

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, Couldhave, 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

software project management (spm)-lecture-12

Documents