This document discusses planning for a software project management session. It covers phases in software development in detail, including lifecycle planning and project plans. It discusses primary planning steps and key planning documents like the Software Development Plan and Risk Management Plan. It also outlines key product documents produced during planning like the Statement of Work, Requirements Document, and Design Specification.
Software Engineering is the set of processes and tools to develop software. Software Engineering is the combination of all the tools, techniques, and processes that used in software production. Therefore Software Engineering encompasses all those things that are used in software production like :
Programming Language
Programming Language Design
Software Design Techniques
Tools
Testing
Maintenance
Development etc.
These days object-oriented programming is widely being used. If programming languages will not support object-orientation then it will be very difficult to implement object-oriented design using object-oriented principles. All these efforts made the basis of software engineering.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Software Project Management | An Overview of the Software Project ManagementAhsan Rahim
Management is the process of getting things done through others, it is the process of coordinating people & other resources to achieve the goals of the organization. A project is a set of related tasks that are coordinated to achieve a specific objective in a given time limit. A project is well-defined task, which is a collection of several operations done in order to achieve a goal. Software is the program & all associated documentation & configuration data which is needed to make these programs operate correctly.
A Software Project is the complete procedure of software development from requirement gathering to testing & maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product.
Software Engineering is the set of processes and tools to develop software. Software Engineering is the combination of all the tools, techniques, and processes that used in software production. Therefore Software Engineering encompasses all those things that are used in software production like :
Programming Language
Programming Language Design
Software Design Techniques
Tools
Testing
Maintenance
Development etc.
These days object-oriented programming is widely being used. If programming languages will not support object-orientation then it will be very difficult to implement object-oriented design using object-oriented principles. All these efforts made the basis of software engineering.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Software Project Management | An Overview of the Software Project ManagementAhsan Rahim
Management is the process of getting things done through others, it is the process of coordinating people & other resources to achieve the goals of the organization. A project is a set of related tasks that are coordinated to achieve a specific objective in a given time limit. A project is well-defined task, which is a collection of several operations done in order to achieve a goal. Software is the program & all associated documentation & configuration data which is needed to make these programs operate correctly.
A Software Project is the complete procedure of software development from requirement gathering to testing & maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product.
This Presentation will describe you,
01. What is software project management
02. The Role of Software Project Manager
03. Risk Management
04. People Management
not only these point you will have with example.
1 in 20 IT projects deliver on time and satisfy business management.
That means 95% of IT projects are partial or total failures.
This presentation explores the causes, and potential strategies for delivering a project in the 5% bracket.
Chapter 06 of ICT Project Management based on IOE Engineering syllabus. This chapter provides knowledge on project management processes, overlaps of process groups in a phase and mapping of project management.Provided by Project Management Sir of KU.
presentation contains the most important part of the software development engineering which is Requirement Analysis and Specification.
Take a look may be it is helpfull for you.
Thank you
Today as we see, software has become an inseparable part of human life. Almost everything we can look around is managed, controlled by software.
The goal of software project management is to understand, plan, measure, and control the project such that it is delivered on time and on budget. This involves gathering requirements, managing risk, monitoring and controlling progress, and following a software development process.
This Presentation will describe you,
01. What is software project management
02. The Role of Software Project Manager
03. Risk Management
04. People Management
not only these point you will have with example.
1 in 20 IT projects deliver on time and satisfy business management.
That means 95% of IT projects are partial or total failures.
This presentation explores the causes, and potential strategies for delivering a project in the 5% bracket.
Chapter 06 of ICT Project Management based on IOE Engineering syllabus. This chapter provides knowledge on project management processes, overlaps of process groups in a phase and mapping of project management.Provided by Project Management Sir of KU.
presentation contains the most important part of the software development engineering which is Requirement Analysis and Specification.
Take a look may be it is helpfull for you.
Thank you
Today as we see, software has become an inseparable part of human life. Almost everything we can look around is managed, controlled by software.
The goal of software project management is to understand, plan, measure, and control the project such that it is delivered on time and on budget. This involves gathering requirements, managing risk, monitoring and controlling progress, and following a software development process.
Project scope can be described as "the work that needs to be accomplished to deliver the End Result (product or service or other project's objectives) with the specified features and functions that includes meetings, reports, analysis and all the other parts of Project Management.
Read| The latest issue of The Challenger is here! We are thrilled to announce that our school paper has qualified for the NATIONAL SCHOOLS PRESS CONFERENCE (NSPC) 2024. Thank you for your unwavering support and trust. Dive into the stories that made us stand out!
Biological screening of herbal drugs: Introduction and Need for
Phyto-Pharmacological Screening, New Strategies for evaluating
Natural Products, In vitro evaluation techniques for Antioxidants, Antimicrobial and Anticancer drugs. In vivo evaluation techniques
for Anti-inflammatory, Antiulcer, Anticancer, Wound healing, Antidiabetic, Hepatoprotective, Cardio protective, Diuretics and
Antifertility, Toxicity studies as per OECD guidelines
Honest Reviews of Tim Han LMA Course Program.pptxtimhan337
Personal development courses are widely available today, with each one promising life-changing outcomes. Tim Han’s Life Mastery Achievers (LMA) Course has drawn a lot of interest. In addition to offering my frank assessment of Success Insider’s LMA Course, this piece examines the course’s effects via a variety of Tim Han LMA course reviews and Success Insider comments.
Embracing GenAI - A Strategic ImperativePeter Windle
Artificial Intelligence (AI) technologies such as Generative AI, Image Generators and Large Language Models have had a dramatic impact on teaching, learning and assessment over the past 18 months. The most immediate threat AI posed was to Academic Integrity with Higher Education Institutes (HEIs) focusing their efforts on combating the use of GenAI in assessment. Guidelines were developed for staff and students, policies put in place too. Innovative educators have forged paths in the use of Generative AI for teaching, learning and assessments leading to pockets of transformation springing up across HEIs, often with little or no top-down guidance, support or direction.
This Gasta posits a strategic approach to integrating AI into HEIs to prepare staff, students and the curriculum for an evolving world and workplace. We will highlight the advantages of working with these technologies beyond the realm of teaching, learning and assessment by considering prompt engineering skills, industry impact, curriculum changes, and the need for staff upskilling. In contrast, not engaging strategically with Generative AI poses risks, including falling behind peers, missed opportunities and failing to ensure our graduates remain employable. The rapid evolution of AI technologies necessitates a proactive and strategic approach if we are to remain relevant.
Operation “Blue Star” is the only event in the history of Independent India where the state went into war with its own people. Even after about 40 years it is not clear if it was culmination of states anger over people of the region, a political game of power or start of dictatorial chapter in the democratic setup.
The people of Punjab felt alienated from main stream due to denial of their just demands during a long democratic struggle since independence. As it happen all over the word, it led to militant struggle with great loss of lives of military, police and civilian personnel. Killing of Indira Gandhi and massacre of innocent Sikhs in Delhi and other India cities was also associated with this movement.
Acetabularia Information For Class 9 .docxvaibhavrinwa19
Acetabularia acetabulum is a single-celled green alga that in its vegetative state is morphologically differentiated into a basal rhizoid and an axially elongated stalk, which bears whorls of branching hairs. The single diploid nucleus resides in the rhizoid.
Palestine last event orientationfvgnh .pptxRaedMohamed3
An EFL lesson about the current events in Palestine. It is intended to be for intermediate students who wish to increase their listening skills through a short lesson in power point.
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdfTechSoup
In this webinar you will learn how your organization can access TechSoup's wide variety of product discount and donation programs. From hardware to software, we'll give you a tour of the tools available to help your nonprofit with productivity, collaboration, financial management, donor tracking, security, and more.
5. Time Allocation by Phase
• Remember the 40-20-40 Rule
• Specification-Implementation-Test
Planning
Code &
Unit Test
Integration &
Test
Commercial
DP
25%
40%
35%
Internet
Systems
55%
15%
30%
Real-time
Systems
35%
25%
40%
Defense
Systems
40%
20%
40%
Bennatan, E.M, “On Time Within Budget”
5
6. Time Allocation by Phase
Activity
Small Project
(2.5K LOC)
Large Project
(500K LOC)
Analysis
10%
30%
Design
20%
20%
Code
25%
10%
Unit Test
20%
5%
Integration
15%
20%
System test
10%
15%
McConnell, Steve, “Rapid Development”
6
7. Activities by % of Total Effort
NASA’s “Manager’s Handbook for Software Development”
7
9. Concept Exploration
• The “Why” phase
• Not a “mandatory formal” phase
– Sometimes called the “pre-project” phase
• Collecting project ideas
– Then the “funneling” process
• Project Justification
– ROI
– Cost-benefit analysis
– Project Portfolio Matrix
• Initial planning and estimates
9
10. Concept Exploration
• Possibly includes Procurement Management:
• RFP Process
• Vendor selection
• Contract management
• Gathering the initial team
– Including PM if not already on-board
• Identify the project sponsor
– Primary contact for approval and decision making
• Potential Phase Outputs:
– Concept Document, Product Description, Proposal,
SOW, Project Charter
10
11. Concept Exploration
• Characteristics & Issues
– Lack of full commitment and leadership
– Some frustrations:
• Management only getting rough estimates from development
• Development not getting enough specifics from customer
• Finding a balanced team
– Budget sign-off may be your 1st major task
– Achieved via:
• Good concept document or equivalent
• Demonstration of clear need (justification)
• Initial estimates
11
12. Requirements
• The “What” phase
• Inputs: SOW, Proposal
• Outputs:
– Requirements Document (RD)
• a.k.a.Requirements Specification Document (RSD)
• Software Requirements Specification (SRS)
– 1st Project Baseline
– Software Project Management Plan (SPMP)
– Requirements Approval & Sign-Off
• Your most difficult task in this phase
12
13. Requirements
•
•
•
•
Perhaps most important & difficult phase
Shortchanging it is a ‘classic mistake’
Can begin with a Project Kickoff Meeting
Can end with a Software Requirements
Review (SRR)
– For Sponsor and/or customer(s) approval
13
15. Requirements
• Characteristics & Issues
– Conflict of interest: developer vs. customer
– Potential tug-of-war:
• Disagreement on Features & Estimates
• Especially in fixed-price contracts
– Frequent requirements changes
– Achieving sign-off
• Project planning occurs in parallel
15
16. Requirements
• Requirements are capabilities and condition
to which the system – more broadly, the
project – must conform
16
17. 2 Types of Requirements
– Functional (behavioral)
– Features and capabilities
– Non-functional (a.k.a. “technical”) (everything else)
– Usability
» Human factors, help, documentation
– Reliability
» Failure rates, recoverability, availability
– Performance
» Response times, throughput, resource usage
– Supportability
» Maintainability, internationalization
– Operations: systems management, installation
– Interface: integration with other systems
– Other: legal, packaging, hardware
17
18. Requirements
• Other ways of categorizing
– Go-Ahead vs. Catch-up
• Relative to competition
– Backward-looking vs. Forward-looking
• Backward: address issues with previous version
• Forward: Anticipating future needs of customers
• Must be prioritized
• Must-have
• Should-have
• Could-have (Nice-to-have: NTH)
• Must be approved
18
20. Analysis & Design
• The “How” Phases
• Inputs: Requirements Document
• Outputs:
–
–
–
–
–
–
Functional Specification
Detailed Design Document
User Interface Specification
Data Model
Prototype (can also be done with requirements)
Updated Plan (improved estimates; new baseline)
20
21. Analysis & Design
• a.k.a. Top-level design & detailed design
• Continues process from RD
• Ends with Critical Design Review (CDR)
– Formal sign-off
– Can also include earlier Preliminary Design
Review (PDR) for high level design
21
22. Analysis & Design
• Characteristics & Issues
– Enthusiasm via momentum
– Team structure and assignments finalized
– Delays due to requirements changes, new
information or late ideas
– Issues around personnel responsibilities
– Unfeasible requirements (technical complexity)
– Resource Issues
• Including inter-project contention
22
23. Development
• The “Do It” phase
• Coding & Unit testing
• Often overlaps Design & Integration phases
– To shorten the overall schedule
– PM needs to coordinate this
23
24. Development
• Other concurrent activities
–
–
–
–
–
–
Design completion
Integration begins
Unit testing of individual components
Test bed setup (environment and tools)
Project plans updated
Scope and Risk Management conducted
24
25. Development
• Characteristics
– Pressure increases
– Staffing at highest levels
– Often a “heads-down” operation
• Issues
–
–
–
–
Last-minute changes
Team coordination (esp. in large projects)
Communication overhead
Management of sub-contractors
25
26. Integration & Test
• Evolves from Dev. Phase
• Often done as 2 parallel phases
– Partial integration & initial test
• Starts with integration of modules
• An initial, incomplete version constructed
• Progressively add more components
26
27. Integration & Test
• Integration primarily a programmer task
• Test primarily a QA team task
• Integration:
– Top-down: Core functionality first, empty
shells for incomplete routines (stubs)
– Bottom up: gradually bind low-level modules
– Prefer top-down generally
27
28. Integration & Test
• Tests
–
–
–
–
–
Integration testing
Black & White-box testing
Load & Stress testing
Alpha & Beta testing
Acceptance testing
• Other activities
– Final budgeting; risk mgmt.; training;
installation preparation; team reduced
28
29. Integration & Test
• Characteristics & Issues
–
–
–
–
–
–
–
Increased pressure
Overtime
Customer conflicts over features
Frustration over last-minute failures
Budget overruns
Motivation problems (such as burnout)
Difficulty in customer acceptance
• Esp. true for fixed-price contracts
29
30. Deployment & Maintenance
• Installation depends on system type
– Web-based, CD-ROM, in-house, etc.
• Migration strategy
• How to get customers up on the system
– Parallel operation
• Deployment typically in your project plan,
maintenance not
30
31. Deployment & Maintenance
• Maintenance
– Fix defects
– Add new features
– Improve performance
• Configuration control is very important here
• Documents need to be maintained also
• Sometimes a single team maintains multiple
products
31
32. Deployment & Maintenance
• Characteristics & Issues
–
–
–
–
–
–
Lack of enthusiasm
Pressure for quick fixes
Insufficient budget
Too many patches
Personnel turnover
Regression testing is critical
• Preferably through automated tools
32
33. Lifecycle Planning
•
•
•
•
a.k.a. Lifecycle Management or SDLC
Greatly influences your chance of success
Not choosing a lifecycle is a bad option
Three primary lifecycle model components
– Phases and their order
– Intermediate products of each phase
– Reviews used in each phase
33
34. Lifecycle Planning
• Different projects require different approaches
• You do not need to know all models by name
• You should know how that if given a certain
scenario what sort of SDLC would be appropriate
• There are more than covered here
• A lifecycle is not a design, modeling or
diagramming technique
– The same technique (UML, DFD, etc) can be used with
multiple lifecycles
34
35. Pure Waterfall
• The “granddaddy” of models
• Linear sequence of phases
– “Pure” model: no phases overlap
• Document driven
• All planning done up-front
35
36. Waterfall Risk
• Why does the waterfall model “invite risk”?
• Integration and testing occur at the end
– Often anyone’s 1st chance to “see” the program
36
37. Pure Waterfall
• Works well for projects with
– Stable product definition
– Well-understood technologies
– Quality constraints stronger than cost &
schedule
– Technically weak staff
• Provides structure
• Good for overseas projects
37
38. Pure Waterfall
• Disadvantages
– Not flexible
• Rigid march from start->finish
– Difficult to fully define requirements up front
– Can produce excessive documentation
– Few visible signs of progress until the end
38
39. Code-and-Fix
• “Code-like-Hell”
• Specification (maybe), Code (yes), Release
(maybe)
• Advantages
– No overhead
– Requires little expertise
• Disadvantages
– No process, quality control, etc.
– Highly risky
• Suitable for prototypes or throwaways
39
41. Spiral
• Emphasizes risk analysis & mgmt. in each phase
• A Series of Mini-projects
• Each addresses a set of “risks”
– Start small, explore risks, prototype, plan, repeat
• Early iterations are “cheapest”
• Number of spirals is variable
– Last set of steps are waterfall-like
41
42. Spiral
• Advantages
– Can be combined with other models
– As costs increase, risks decrease
– Risk orientation provides early warning
• Disadvantages
– More complex
– Requires more management
42
43. Modified Waterfall – Sashimi
• Overlapping phases
• Advantages
– Reduces overall schedule
– Reduces documentation
– Works well if personnel continuity
• Disadvantages
– Milestones more ambiguous
– Progress tracking more difficult
– Communication can be more difficult
43
44. Evolutionary Prototyping
• Design most prominent parts first
– Usually via a visual prototype
• Good for situations with:
– Rapidly changing requirements
– Non-committal customer
– Vague problem domain
• Provides steady, visible progress
• Disadvantages
– Time estimation is difficult
– Project completion date may be unknown
– An excuse to do “code-and-fix”
44
45. Staged Delivery
• Waterfall steps through architectural design
• Then detailed design, code, test, deliver in stages
• Advantages
•
•
•
•
•
Customers get product much sooner
Tangible signs of progress sooner
Problems discovered earlier
Increases flexibility
Reduces: status reporting overhead & estimation error
• Disadvantages
• Requires more planning (for you the PM)
• More releases increase effort (and possible feature creep)
• How’s this differ from Evolutionary Prototyping?
45
47. V Process Model
• Designed for testability
– Emphasizes Verification & Validation
• Variation of waterfall
• Strengths
– Encourages V&V at all phases
• Weaknesses
– Does not handle iterations
– Changes can be more difficult to handle
• Good choice for systems that require high
reliability such as patient control systems
47
48. RAD
• Rapid Application Development
• Popular in the 80’s
– 1. Joint Requirements Planning (JRP)
– 2. Joint Application Design (JAD)
– 3. Construction
• Heavy use of tools: code generators
• Time-boxed; many prototypes
– 4. Cutover
• Good for systems with extensive user input
available
48
49. COTS
• Commercial Off-The-Shelf software
• Build-vs.-buy decision
• Advantages
– Available immediately
– Potentially lower cost
• Disadvantages
– Not as tailored to your requirements
• Remember: custom software rarely meets its ideal
(so compare that reality to COTS option)
49
50. XP: eXtreme Programming
• Not a Microsoft product
• Part of movement called “Agile
Development”
• A “Lightweight” methodology
• A bit counter-culture
• Currently in vogue
• Motto: “Embrace Change”
• Highly Incremental / Iterative
50
52. eXtreme Programming
•
•
•
•
•
•
•
•
Suitable for small groups
Attempts to minimize unnecessary work
Uses an “on-site” customer
Small releases
Pair programming
Refactoring
Stories as requirements
You want good developers if you use this
52
53. Other “Agile” Methodologies
• Agile here means “lite”, reduced docs,
highly iterative
• Agile Software Development
– Alliance , their “manifesto”, their book
• SCRUM
– Features 30-day “Sprint” cycles
• Feature Driven Development (FDD)
– XP with more emphasis on docs and process
53
54. Other “Agile” Methodologies
• Adaptive Software Development (ASD)
– Book, site
• Dynamic System Development Method
(DSDM)
– Popular in Europe
• Homegrown: developers often hide their
“agile adventures” from management
54
55. Other “Agile” Methodologies
• Pros
– Similar to XP, can reduce process overhead
– Responsive to user feedback
– Amenable to change
• Cons
– Requires close monitoring by PM
– May not “scale” to large projects
– Often requires better quality developers
55
58. Rational Unified Process
•
•
•
•
•
•
•
•
•
Develop Iteratively
Manage Requirements
Uses UML (Unified Modeling Language)
Produces “artifacts”
Use component-based architecture
Visually model software
Complex process
A “framework”
Suitable for large scale systems
58
59. Choosing Your Lifecycle
•
•
•
•
•
•
•
Varies by project
Opt for “iterative” or “incremental”
How well are requirements understood?
What are the risks?
Is there a fixed deadline?
How experienced is the team or customer?
See the table in McConnell
59
60. IEEE 1074
• A standard for developing software
processes
–
–
–
–
–
–
Lifecycle model selection
Project management process
Predevelopment processes
Development processes
Post-development processes
Integral process
60
61. Planning
• “Plans are nothing. But planning is
everything.” Gen. Dwight Eisenhower
61
62. Planning
•
•
•
•
Preliminary planning starts on day one
Even in the pre-project phase
Should not be conducted “in secret”
Need buy-in and approval
– Very important step
– Both from above and below
62
63. Your PM Process
• Why
• Deliverable: ROI
• What
• SOW, Requirements
• How
• Design Specification, SDP, Lifecycle
Futrell, Shafer, Shafer, “Quality Software
Project Management”
• Do
• Execution
• Done
• PPR
63
64. Primary Planning Steps
•
•
•
•
•
•
•
•
Identify project scope and objectives
Identify project organizational environment
Analyze project characteristics
Identify project products and activities
Estimate effort for each activity
Identify risk
Allocate resources
Review and communicate plan
64
66. Planning Documents
• Software Development Plan (SDP)
• Software Quality Assurance Plan (SQAP)
• Software Configuration Management Plan
(SCMP)
• Risk Management Plan
• Software Process Improvement Plan
• Communications Management Plan
• Migration Plan
• Operations Plan
66
67. Planning Documents
• You (the PM) need to choose which
documents are appropriate
• Docs do not have to be lengthy
• Small Set:
–
–
–
–
Software Development Plan
Risk Management Plan
Software Quality Assurance Plan
Software Configuration Management Plan
67
68. Planning Documents
•
•
•
•
•
•
•
Project ROI Analysis
Statement of Work (SOW)
Project Charter
Software Project Management Plan (SPMP)
Budget
Responsibility Assignment Matrix (RAM)
Risk Management Plan
68
69. Product Documents
• Statement of Need
• System Interface
Specification
• Software Requirements
Specification
• Software Design
Specification
• Software Validation &
Verification Plan
• User Documentation
• Support Plan
• Maintenance
Documentation
69
70. Software Project Survival Guide
• Another McConnell book
• See construx.com’s SPSG section
–
–
–
–
–
Good content online
Documents
Schedules
Checklists
Project web site template
70
73. Process Issues
• You want a fairly sophisticated process
without incurring much overhead
• Remember, projects are often larger than
they first appear
• Easier to loosen too much process than add
later
73
74. Plans Evolve Over Time
NASA’s “Manager’s Handbook for Software Development”
74
75. Software Development Plan
• Software Project Management Plan (SPMP)
• Some consider it the most important
document in the project (along with SRS)
– Can be seen as an aggregation of other core
documents
• Evolves over time as pieces come together
• McConnell’s example
75
77. Communications Management Plan
• Often a section of SPMP
• Describes information flow to all parties
– Gathering and distributing information
• Status meetings
– Monthly, Weekly, Daily?
– Status reports are vital
77
78. Create a Project Intranet
• A great communications tool
• Reference all project resources here
78