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
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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.
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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.)
7/30/2019 Software Project Management (SPM)-Lecture-12
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/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
9/19
5/1/2013 9
7/30/2019 Software Project Management (SPM)-Lecture-12
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)
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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.
7/30/2019 Software Project Management (SPM)-Lecture-12
15/19
5/1/2013 15
Samples for Partial Implementations of the Spiral Model
7/30/2019 Software Project Management (SPM)-Lecture-12
16/19
5/1/2013 16
Th St t d E l ti
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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
7/30/2019 Software Project Management (SPM)-Lecture-12
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
Top Related