UNIT – 1

Software Project Management – Life Cycles Activities

Layered Technology
• Tools, Methods, Process Model, Quality Focus
Essence of Practice
• Understand the Problem (communication and analysis)
• Plan a Solution (modeling and design)
• Carry out a plan (Code Generation)
• Examine the Result for accuracy (testing and quality assurance)
Factors Influencing Project Management
• Company size, software customers, software type, software size, organizational culture, software development processes
Software Management Lifecycle Activities (SMLA)
• Proposal writing
• Proposal planning
• Risk management
• People management
• Reporting
Software Development Life Cycle (SDLC)
• Traditional Software Process Models
o Waterfall (when requirements are very clear, no changes in future)

o V Model
▪ Developed waterfall model with more testing
o Prototype (when requirements are not clear)

o Spiral (when risk factor is high, iterated until manager is satisfied)

▪ Cost, effort, time depends on the width of the spiral
o RAD (experienced team & motivated to speed up development, users sophisticated with goals of company)
(For quick results)
▪ Normal Approach (board phases of RAD)
• Requirements Planning
• RAD design workshop
• Implementation
▪ Martin Approach
• Requirement planning
• User Design
• Construction
• Cutover
• Conventional Software Process Models
o Agile (move quickly, accept changes in less time with frequent delivery in face-to-face communication)
▪ Large projects => small chunks (Iterations) => Release => feedback => enhance => rerelease
 o XP
▪ XP Planning
• set of stories – user stories, assign cost and delivery date for each story
• After first increment – project velocity decides subsequent delivery dates
▪ XP Design (KIS principle)
• Use of CRC cards and refactoring (iterative refinement of the internal program design)
• Spike solutions – design prototype
▪ XP Coding
• Recommends unit testing and encourages pair programming
▪ XP Testing
• Unit testing daily and Acceptance tests defined by customer
o Scrum

Requirement Engineering
• Inception (ask a set of questions to know requirements)
• Elicitation (elicit requirements from all stakeholders – meeting, rules, agenda, facilitator, definition mechanism)
• Elaboration (create analysis model that identifies data, function and behavioral requirements)
o Scenario based (functional, use case), Class based, Behavioral based (state diagram), Data flow diagram
• Negotiation (agree on a deliverable system that is realistic for developers and customers)
• Specification
o Written document, set of models, formal mathematical, collection of user scenarios, prototype
• Validation (review mechanism that looks for errors, clarification areas, missing info, inconsistencies, conflicting
requirements)
• Inception (identify stake holders, collaborative work, recognize multiple POV)
Software Project Effort and Cost Estimation
• Cost per LOC = Labor rate per month/LOC per pm
• Total Estimated Project Cost = Estimated LOC * Cost per LOC
• Estimated Effort in pm = Total Estimated Project Cost/ Labor rate per month
Cost Estimation (Constructive Cost Model)
• COCOMO 1
 • COCOMO 2
o PROD = NOP / person-month
o Estimated effort = NOP / PROD
o Object points = screen + report + components
o NOP = Object Points * [(100 - % reuse)/100]
o Estimated Effort = NOP/PROD

Risk Management
• Characteristics of risk (Uncertainty, Loss)
• Risk Categorization (Approach 1)
o Project Risks
o Technical Risks
o Business Risks
o Sub-Categories of Business Risks
• Risk Categorization (Approach 2)
o Known Risks & Predictable Risks
▪ Product size, customer characteristics, Process definition, Development environment, Technology to
be built, staff size and experience
o Unpredictable Risks
• Risk Strategies
o Reactive Risk Strategies
o Proactive Risk Strategies
• Steps for Risk Management, Risk Identification, Risk Item Checklist
• Risk components and Drivers
o Performance Risk
o Cost Risk
o Support Risk
o Schedule Risk
• Risk Projection, Risk Table, Developing Risk Table, Assessing Risk Impact
• Risk Mitigation, Monitoring and Management (RMMM)
o Mitigation (avoidance)
o Monitoring (observing)
o Management
• Seven Principles of Risk Management
o Maintain global perspective
o Take a forward-looking view
o Encourage open communication
o Integrate risk management
o Emphasize a consideration of risk management
o Develop a shared product vision
o Encourage teamwork when managing risk
Configuration Management
Project Planning
• WBC (work breakdown structure, Time line Charts)
• Planning
• Scope (People, environment, reusable software)
• Risk

• Scheduling principles
o Compartmentalization – Define distinct tasks
o Interdependency – Indicate task interrelationship
o Effort validation – Be sure resources are available
o Defined responsibilities – People must be assigned
o Defined outcomes – Each task must have an output
o Defined milestones – Review for Quality
 UNIT – 2
Software Design
Design Standards – Design Type
Design Model
• Architectural Design
• Software Architecture
Software Design Methods
• Top Down
• Bottom Up
• Module Division (Refactoring)
• Module Coupling

Component Level Design

User Interface Design
Pattern Oriented Design
Web Application Design

Design Reuse
Concurrent Engineering in Software Design
Design Life-Cycle Management
 UNIT – 3
Software Construction
➢ Labor Intensive, 30% efforts, contains many tasks, Individual or Teams are formed, max effect on final product
➢ Parallel development – concurrent engineering (work as teams in parallel)
➢ follow proven process for maintainable, testable, reliable code production with max resource utilization
Coding Standards
➢ Developers are given Software Design Specifications – Use Cases, User Interface, ERD, Flow Diagrams etc.,

• Modularity
• Clarity
• Simplicity
• Reliability
• Safety
• Maintainability
Coding Framework
➢ Consistent coding production – easy to debug and test, Inheritance in OOP
➢ Allow construction of common infrastructure of base functionality which can be extended by developers
➢ It increases Productivity, robust, structured Product
Reviews
➢ 70% defects from faulty code, rework wastes money & effort, cheap to fix during construction, Expensive during testing

• Quality Control
o Different Stages with different purposes in software code writing
o Deals with Approval of code rather than checking for defects
• Desk Checks (Peer Reviews)
o Employed when a complete review of source code not important
o Developer sends code to team members => they review and send feedback & comments & suggestions
o Developer either incorporate or discard as review is voluntary but powerful tool for defect elimination
• Walkthroughs
o Formal code review. Send Invitation => Present method of coding => Suggestions from team members
o Developer Decides to incorporate or discard suggestions
• Code Reviews
o Most formal method. Project Manager arranges meet
o Team members point out code errors, defects, improper code, important code logic
o Error log is generated by whole team
• Inspections
o Final review. Decides whether to pass piece of code for inclusion into main software build
Coding Methods
• Structured Programming
• Object-Oriented Programming
Automatic Code Generation
Software Code reuse
➢ Procedural Programming – special functions, utility libraries, etc.,
➢ OOP – reuse is at more advanced level – class, Inheritance
➢ Service Oriented Architecture - SOA
Pair Programming
➢ Employed in eXtreme Programming Development tool. Development assigned to 2 developers.
➢ One developer writes code, other guides through requirements (functional, nonfunctional)
➢ Swaps places for coding and coaching work
➢ Makes developer understand requirements and construct better code with less defects
Test-Driven Development
➢ Iteration-based Projects with eXtreme Programming technique. Here tests drive development
➢ Test case-based logic building. With perfect logic, code is written.
Configure Management
➢ Many Versions due to change in design. Chance of working on wrong version.
➢ Developer can break the build of other version with bad piece of code which halts development until it is rebuild
➢ Smoke test application – for developers from different places (automate system mails for wrong code)
Software Construction Artifacts
 UNIT – 4
Software testing scenarios
• More than required testing => Waste of time and money
• Less than required testing => High cost of support
• No testing => Impossible to support
Problems with Traditional testing (too little and too late)
➢ there could be many faulty requirement specifications and faulty software design
➢ Challenging and Costly, Time Taking, Infeasible
Quality Standard Documents
• Verification => Static Testing (Observe source Code)
o checking requirement specifications, design, source code etc.,
o Do not run Source Code (dead code, unused code, faulty logic etc.,)
• Validation => Dynamic Testing (Actual running of Source Code)
o Unit - testing source code by small modules
o Integration - tested when integrated with other application
o System –
o User acceptance - testing by end user
Testing Strategy and Planning
• Planning
o work breakdown structure, requirement review, resource allocation, effort estimation
o tools selection, setting up communication channels, etc.,
• Test Prioritization
o Focus on Features which are used most by user
• Risk Management
o causes are unrealistic schedule, resource unavailability, skill unavailability, frequent requirement changes
o overconfidence of employees (test manager, HR, marketing team)
o delay of resources (human and material)
• Effort Estimation
o scheduling, resource planning and budget for a test project
o project size, productivity, and test strategy
o wideband Delphi technique, experience-based estimation
• Test Point Analysis
o Product size (no. of function points)
o Test strategy (Quality level + Priority areas)
o productivity (Experience + Skills)
Test Project Monitoring and Control
• Test Case Design
o what kind, how many per modules and priority modules
Test Types
▪ functionality, performance, usability, compatibility
▪ Regression tests for applications having multiple versions
▪ Verification and Validation
• Test Case Writing/Management
• Test Script Creation/Bed Preparation
o installing the application on a machine that is accessible to all test teams
o "Application under test", testing application in which it is meant for (example APP in android)
o test data preparation is very tricky
• Test Case Execution
Defect Tracking
(Testers should stay until application is deployed, if Testers are on contract schedule should be taken care)
o Defect Logging
o Assign Defect
 o Fix Defect
o Defect Verification
o Defect Closure
• Test Case Closure

Test Bed Preparation

Assume it as... Hosting on GitHub... Giving access to a particular set of people or to a team and they will test it
I might get an error... If I run again, I might not get the same error...
To avoid these... They completely isolate the testing file with other files so that it works the same every time (whether it be an
error or correct execution)
 UNIT - 5
Product Release

Product Release Management Tasks

Estimate cost of providing support
Selection of software version to be shipped
Decision for alpha, beta or regular release
Create walk around for known defects
Provide training to support staff
Make customer support strategy

Product Release Management

- pressure to launch new versions, new features
- porting to new platform
- half-baked product

Product Release Types

Alpha release
Beta release
Internal release
Normal release

Production implementation tasks (product run smoothly, problems due to unforeseen circumstances, recommended to
prepare a list of developer requirements)
Check software interfaces
Check hardware interfaces
Create master data
Create test data
Create user accounts
Check infrastructure for installation

User Training
- User manual (or) Tutorials up to date and sync with present version
- Not possible to train all users
- Very important step

Maintenance (more than 70% of all costs associated with software product development, implementation, and support and
maintenance)
Technology obsolescence
Software defects
Change in user requirements

Reasons for software maintenance

Software defects
New user requirement
Changed user requirement
Technology obsolescence
Better technology
Software Maintenance Types
Corrective
User finds a bug while using => reports => maintenance team plans and fixes => user uses
Preventative
change in business/operative or hardware/software environment => affect software operation =>
maintenance to reuse product
Perfective
change in business environment => additional/modified functionality needed
Adaptive
change in software or hardware interface => adaptive maintenance to reuse software
Maintenance Cost
Revenue Loss
Opportunity Loss
Productivity Loss

Maintenance Process
Quick fix Model
Immediately fixed without any planning
Boehm’s model
Boehm’s model is based on economic models and often involves calculating ROI, for any planned
maintenance. If ROI turns out to be good, then it is carried out or else it is dropped
Osborne’s model
Change requests
Quality Assurance
Metrics
Reviews
Iterative enhancement model
Similar to iterative software development
High priority fixed first, low priority fixed next
Reuse oriented model
Component-based software products
Existing components are analysed and changes are made
Maintenance Life Cycle (crucial part, lot of time and effort)
List of defects
Subset of defects
Defect fixing planning/execution
Patch application
Test application
Maintenance complete

Maintenance techniques
Reengineering (reuse technology)
each defect is specifically analyzed to find out the root cause of the defect
Forward engineering (opposite of reverse engineering)
we have ample documentation about the existing product
existing product needs to be extended so that the new needs can be fulfilled
Reverse engineering
when nonexistent or sketchy documentation is available for the software product

Software release Case Study

THANK
YOU