GMP Session 3&4
-
Upload
barathy-arvind -
Category
Documents
-
view
123 -
download
2
Transcript of GMP Session 3&4
Project Management
Planning Phase Focus :
Why build this system? How to structure the project?
Primary Outputs System request with feasibility studyProject Plan
StepsIdentify opportunity Analyse feasibility Develop work plan Staff project Control and direct project
Analysis Phase
Focus: Who, What and Where and when for this system
Primary outputSystem proposal
Steps Develop analysis strategy Determine business requirementCreate use cases Model processes Model data
Design Phase
Focus: How will this system work?
Primary output: System Specification
Steps Design Physical system Design architecture Design Interface Design Databases and files
Implementation Phase
Focus: Delivery and support of completed System
Primary output: Installed System
StepsConstruct System Install System Maintain System Post Implementation
Project Identification and Initiation
A project is identified when someone in the organization identifies a business need to build a system.A need may surface when an organization identifies unique and competitive ways of using IT.Emerging technologies.Both IT people and business people should work together to find way for technology to support business needs.The project sponsor is someone who recognizes the strong business need for a system.
This individual will work throughout the SDLC to make sure that the project is moving in the right direction from the perspective of the business.Serves as the primary point of contact for the system.Size and scope of the project is determined by the kind of sponsor that is needed.The project sponsor also should have an idea of the business value to be gained from the system, in both tangible and intangible ways.Tangible value can be quantified and measured easily (reduction in operating costs).An intangible value is based on the belief that the system is important; however, benefits are hard to measure.
Project Sponsor
The document that describes the business reasons for building a system and the value that system is expected to provide.The project sponsor usually completes this form as part of a formal system selection process within the organization.
System Request
Elements of system request
Project SponsorProject need Business requirement Business value Special issues and constraints
Too much paper Part 1Sponsor:
Document Manager.
Business Need: Increase efficiency in storing, updating, and retrieving information on
employee injury claims.
Business Requirements: Automated system which allows for electronic submission of reports via
a secure web site.
Business Value: Reduce response time for employee inquiries, increase effectiveness of
storing, updating, and retrieving employee injury claims.
Special Issues: Must have someone who understands how to create and maintain a
secure web site. Must have resources to migrate paper files to data storage. Must work within Govt guidelines to ensure that medical documents are treated according to regulations.
The completed system request is submitted to the approval committee for consideration.The committee reviews the system request and makes an initial determination, based on the information provided, of whether to investigate the proposed project or not.If so, the next step is to conduct a feasibility analysis.
Feasibility analysis guides the organization in determining whether to proceed with a project.Feasibility analysis also identifies the important risks associated with the project that must be addressed if the project is approved.
Feasibility Analysis
As with the system request, each organization has its own process and format for the feasibility analysis.Most include techniques to assess three areas:
Technical feasibilityEconomic feasibilityOrganizational feasibility
The results of these techniques are combined into a feasibility study deliverable that is given to the approval committee at the end of the project initiation.
Too much paper Part 2 Issues arising from digital signatures and electronic documents typically focus on establishing validity for signatures and originators. As these issues can be overcome using certificates and encryption, they don’t necessarily affect the project feasibility. However, they do need to be addressed.Show the clerks how their jobs might be easier to accomplish by presenting them with a projection of how the new system will allow them to reduce the response time to customers and to allow for more efficient updating of the files.
Consider the Amazon.com Web site. The management of the company decided to extend their Web-based system to include products other than books. (e.g., wine, specialty gifts). How would you have assessed the feasibility of the venture when the idea first came up? How "risky" would you have considered the project that implemented this idea? Why?
Technical Feasibility – Not a concern since the base system we use for selling books is easily adaptable to other products.
Economic Feasibility – Would need to carefully analyze sales projections for the various proposed product lines. Should be able to determine costs associated with this fairly accurately
Organizational Feasibility – They are the pioneers in web-based retail; broadening their product line beyond books makes good strategic sense.
Gartner Quadrant for Portfolio Management Software Solutions in the IT-Sector
The Gartner Group is a large US-based
consulting organization whose focus is primarily
the IT-field. The Gartner Group
periodically reviews the Project Portfolio
Management software solutions which are
available on the market and ranks these in its
acclaimed “Magic Quadrant for IT Project
and Portfolio Management”.
Project Classification
Project Selection • Option 1: • Costs: expenses for writing ad hoc reporting programs,
expenses for maintaining ad hoc reporting programs, expenses associated with maintaining staff with CICS expertise
• Benefits: employees already understand the new system, shorter short-term costs, no employees would be replaced by automated system
• Risks: Continued low performance of premiums to claim payment ratios, possible loss of data integrity, no processes available for auditing performance, possible law suits associated with low premium to claim payment ratio
• Option 2: • Costs: expenses for writing a dynamic retrieval
program, expenses for maintaining a dynamic retrieval program, expenses associated with training staff with new functionality
• Benefits: data would be more accurate, users would be able to view required data, less costly than developing a new system
• Risks: difficult to develop processes for auditing performance, difficult for the program to provide a relationship among the data, more costly than Option 1
•
• Option 3:• Costs: expenses for software, expenses for outside
consultants, expenses associated with employees taking time away from work to learn new program
• Benefits: auditable processes, reliability of data, relational capability among data stores
• Risks: Possible compromise of proprietary information through consultants, costlier than other two options, time taken for development and implementation
•
Project Methodology Options
Waterfall Development
Parallel Development
V-model (variation of the Waterfall Development
Prototype
Rapid Application Development (RAD)
Iterative Development
Agile Development
Waterfall Development
Waterfall Strengths
Easy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan, staff, track)Works well when quality is more important than cost or schedule
Waterfall Deficiencies
All requirements must be known upfrontDeliverables created for each phase are considered frozen – inhibits flexibilityCan give a false impression of progressDoes not reflect problem-solving nature of software development – iterations of phasesIntegration is one big bang at the endLittle opportunity for customer to preview the system (until it may be too late)
When to use the Waterfall Model
Requirements are very well knownProduct definition is stableTechnology is understoodNew version of an existing productPorting an existing product to a new platform.
Parallel Development
V-model
V-Shaped Strengths
Emphasize planning for verification and validation of the product in early stages of product developmentEach deliverable must be testableProject management can track progress by milestonesEasy to use
V-Shaped Weaknesses
Does not easily handle concurrent eventsDoes not handle iterations or phasesDoes not easily handle dynamic changes in requirementsDoes not contain risk analysis activities
When to use the V-Shaped Model
Excellent choice for systems requiring high reliability – hospital patient control applicationsAll requirements are known up-frontWhen it can be modified to handle changing requirements beyond analysis phase Solution and technology are known
System Prototyping
Prototyping ModelDevelopers build a prototype during the requirements phasePrototype is evaluated by end usersUsers give corrective feedback Developers further refine the prototypeWhen the user is satisfied, the prototype code is brought up to the standards needed for a final product.
Prototyping StrengthsCustomers can “see” the system requirements as they are being gatheredDevelopers learn from customers A more accurate end productUnexpected requirements accommodatedAllows for flexible design and developmentSteady, visible signs of progress producedInteraction with the prototype stimulates awareness of additional needed functionality
Prototyping Weaknesses
Tendency to abandon structured program development for “code-and-fix” developmentBad reputation for “quick-and-dirty” methodsOverall maintainability may be overlookedThe customer may want the prototype delivered.Process may continue forever (scope creep)
When to use Prototyping
Requirements are unstable or have to be clarified As the requirements clarification stage of a waterfall modelDevelop user interfacesShort-lived demonstrations New, original developmentWith the analysis and design portions of object-oriented development.
Example of Throwaway Prototyping
Iterative Development
Iterative Model Strengths
Develop high-risk or major functions firstEach release delivers an operational product Customer can respond to each buildUses “divide and conquer” breakdown of tasksLowers initial delivery cost Initial product delivery is fasterCustomers get important functionality earlyRisk of changing requirements is reduced
Iterative Model Weaknesses
Requires good planning and designRequires early definition of a complete and fully functional system to allow for the definition of incrementsWell-defined module interfaces are required (some will be developed long before others)Total cost of the complete system is not lower
When to use the Iterative Model
Risk, funding, schedule, program complexity, or need for early realization of benefits.Most of the requirements are known up-front but are expected to evolve over timeA need to get basic functionality to the market earlyOn projects which have lengthy development schedulesOn a project with new technology
Agile SDLC’s
Speed up or bypass one or more life cycle phases Usually less formal and reduced scopeUsed for time-critical applicationsUsed in organizations that employ disciplined methods
Some Agile MethodsAdaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Clear Dynamic Software Development Method (DSDM) Rapid Application Development (RAD)Scrum Extreme Programming (XP) Rational Unify Process (RUP)
Extreme Programming - XP
For small-to-medium-sized teams developing software with vague or rapidly changing requirements
Coding is the key activity throughout a software projectCommunication among teammates is done with codeLife cycle and behavior of complex objects defined in test cases – again in code
Example of Extreme Programming
Rapid Application Model (RAD)
Requirements planning phase (a workshop utilizing structured discussion of business problems)User description phase – automated tools capture information from usersConstruction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”)Cutover phase -- installation of the system, user acceptance testing and user training
RAD StrengthsReduced cycle time and improved productivity with fewer people means lower costsTime-box approach mitigates cost and schedule riskCustomer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needsFocus moves from documentation to code (WYSIWYG).Uses modeling concepts to capture information about business, data, and processes.
RAD WeaknessesAccelerated development process must give quick responses to the userRisk of never achieving closure Hard to use with legacy systemsRequires a system that can be modularizedDevelopers and customers must be committed to rapid-fire activities in an abbreviated time frame.
When to use RAD
Reasonably well-known requirementsUser involved throughout the life cycleProject can be time-boxed Functionality delivered in incrementsHigh performance not requiredLow technical risks System can be modularized
Criteria for Selecting a Methodology
Important Factors to Consider
Clarity of User RequirementsFamiliarity with TechnologySystem ComplexitySystem ReliabilityShort Time SchedulesSchedule Visibility
yt-Selecting a Methodology
Throwaway prototyping would be a good choice for this scenario for a number of reasons. First, this is a brand new idea, so there may be some ambiguity or confusion as to the functionality of the system. Second, there are technical issues associated with integrating existing hardware and software due to the diversity at different locations around the world. Third, the time frame to delivery is one year. The time frame would allow for an in-depth analysis to gather information and develop ideas for the system before the design phase. Once the initial requirements were documented, a series of design prototypes can be created, distributed and tested to determine whether issues dealing with functionality or technical problems have been addressed. Once the issues have been resolved, the project can move into design and implementation.
SESSION 4 Requirements Analysis
Become familiar with analysis phase of SDLC Understand how to create a requirements definition Become familiar with requirement analysis techniques Understand when to use and gather requirement using various requirement analysis technique Understand when to use each requirement gathering techniques
Learning Objectives
Introduction
The As-Is system is the current system and may or may not be computerizedThe To-Be system is the new system that is based on updated requirementsThe System Proposal is the key deliverable from the Analysis Phase
Introduction
The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them -- or decide a new system isn’t needed.The System Proposal is presented to the approval committee via a system walk-through.Systems analysis incorporates initial systems design.Requirements determination is the single most critical step of the entire SDLC.
A statement of what the system must do A statement of characteristics the system must haveFocus is on business user needs during analysis phaseRequirements will change over time as project moves from analysis to design to implementation
What is a Requirement?
Functional RequirementsA process the system has to performInformation the system must contain
Nonfunctional RequirementsBehavioral properties the system must have
OperationalPerformanceSecurityCultural and political
Requirement Types
Functional vs. non-functional requirements
Functional: describes an interaction between the system and its environmentExamples:
System shall communicate with external system X.What conditions must be met for a message to be sent
Non-functional: describes a restriction or constraint that limits our choices for constructing a solutionExamples:
Paychecks distributed no more than 4 hours after initial data are read.System limits access to senior managers.
fig_03_01
fig_03_02
Your Turn: Identifying requirements
Functional business requirements: 2, 4, 6, 8. Nonfunctional business requirements: 1, 3, 5, 7, 9, 10.
Review the Amazon.com Web site. Develop the requirements definition for the site. Create a list of functional business requirements that the system meets. What different kinds of nonfunctional business requirements does the system meet? Provide examples of each kind.
Examples of Functional Requirements include:Search - enable user to find item(s) based on variety of item characteristicsBrowse - enable user to look through itemsShop - enable user to select and purchase itemsComment - enable user to submit his/her comments on items and read other users' comments on itemsPersonalize - enable site to remember user's preferences based on previous use of the site and orders placedRegistries - enable user to participate in registry (e.g., wedding, baby); enable users to search registriesWish Lists - enable user to create and maintain a wish list of desired items; enable users to search a person's wish list for gift ideas.
Examples of Non-functional Requirements include:
Operational - the system should work on any web browserPerformance - the system should be available 24/7/365.Security - the system enables registered customers to review their own accountsCultural - the system exists in versions tailored to global users, e.g., French, Japanese, German, etc.
Requirements definition reportText document listing requirements in outline formPriorities may be included
Key purpose is to define the project scope: what is and is not to be included.
Documenting Requirements
fig_03_03
Determining Requirements
Participation by business users is essentialThree techniques help users discover their needs for the new system:
Business Process Automation (BPA)Business Process Improvement (BPI)Business Process Reengineering (BPR)
Basic Process of Analysis (Determining Requirements)
Understand the “As-Is” systemIdentify improvement opportunitiesDevelop the “To-Be” system conceptTechniques vary in amount of change
BPA – small changeBPI – moderate changeBPR – significant change
Additional information gathering techniques are needed as well
Business Process Automation
Goal:
Efficiency for users
Identifying Improvements in As-Is Systems
Problem AnalysisAsk users to identify problems and solutionsImprovements tend to be small and incrementalRarely finds improvements with significant business value
Root Cause AnalysisChallenge assumptions about why problem existsTrace symptoms to their causes to discover the “real” problem
Root Cause Analysis Example
Business Process Improvement
Goal:
Efficiency and
effectivenessfor users
Duration Analysis
Calculate time needed for each process stepCalculate time needed for overall processCompare the two – a large difference indicates a badly fragmented processPotential solutions:
Process integration – change the process to use fewer people, each with broader responsibilitiesParallelization – change the process so that individual step are performed simultaneously
Activity-Based Costing
Calculate cost of each process stepConsider both direct and indirect costsIdentify most costly steps and focus improvement efforts on them
Benchmarking
Studying how other organizations perform the same business processInformal benchmarkingCommon for customer-
facing processesInteract with other
business’ processes as if you are a customer
Conducting a duration analysis would illustrate problem areas in this process, and a process integration analysis would certainly help in reducing the number of steps required to complete the process. One of the major problems in this scenario is that too many departments are involved. reducing the number of departments, or the number of steps required, which would decrease the time involved, would be right on track.
Your Turn: IBM Credit
Business Process Reengineering (BPR)
Goal:
Radical redesign of business
processes
Outcome Analysis
Consider desirable outcomes from customers’ perspectiveConsider what the organization could enable the customer to do
Technology Analysis
Analysts list important and interesting technologiesManagers list important and interesting technologiesThe group identifies how each might be applied to the business and how the business might benefit
Activity Elimination
Identify what would happen if each organizational activity were eliminatedUse “force-fit” to test all possibilities
Comparing Analysis Techniques
Potential business valueProject costBreadth of analysisRisk
Project Characteristics
Requirements Gathering Techniques
Understand when to use and gather requirement using various requirement analysis technique Understand when to use each requirement gathering techniques
Learning Objectives
Problem analysis and benchmarking would be feasible strategies to employ in this situation. This is a problem with a rather narrow scope…the As-Is system needs to be improved, but there is no broadening of the information that needs to be integrated into this system. Problem analysis would permit the analyst to identify potential solutions that the users can identify, then identify the problems those solutions are addressing, and investigate the root causes of the problems. Analysts could also employ informal benchmarking, and investigate systems used by other similar organizations for ideas for this system’s requirements.
Mini Case 1
Recognize the important side effects of the requirement gathering processCarefully determine who is included in the requirement gathering process Respect the time constraint that you are asking the participants to make.
Practical tips for requirement gathering techniques
Interviews QuestionnaireJADDocument Analysis Observation
Requirement Gathering Techniques
Interviews -- Five Basic Steps
Selecting intervieweesDesigning interview questionsPreparing for the interviewConducting the interviewPost-interview follow-up
Selecting Interviewees
Based on information neededOften good to get different perspectives
ManagersUsersIdeally, all key stakeholders
Types of Questions
Types of Questions Examples
Closed-Ended Questions * How many telephone orders are received per day?
* How do customers place orders?* What additional information
would you like the new system to provide?
Open-Ended Questions * What do you think about the current system?
* What are some of the problems you face on a daily basis?
* How do you decide what types of marketing campaign to run?
Probing Questions * Why?* Can you give me an example?* Can you explain that in a bit
more detail?
Designing Interview Questions
Unstructured interviewBroad, roughly defined information
Structured interviewMore specific information
Questioning Strategies
Interview Preparation Steps
Prepare general interview planList of questionAnticipated answers and follow-ups
Confirm areas of knowledgeSet priorities in case of time shortagePrepare the interviewee
ScheduleInform reason for interviewInform areas of discussion
Conducting the Interview
Appear professional and unbiasedRecord all informationCheck on organizational policy regarding tape recordingBe sure you understand all issues and termsSeparate facts from opinionsGive interviewee time to ask questionsBe sure to thank the intervieweeEnd on time
Conducting the InterviewPractical Tips
Don’t worry, be happyPay attentionSummarize key pointsBe concise Be honestWatch body language
Post-Interview Follow-Up
Prepare interview notesPrepare interview reportLook for gaps and new questions
Interview Report
INTERVIEW REPORT
Interview notes approved by: ____________
Person interviewed ______________Interviewer _______________Date _______________
Primary Purpose:
Summary of Interview:
Open Items:
Detailed Notes:
JAD Key Ideas
Allows project managers, users, and developers to work togetherMay reduce scope creep by 50%Avoids requirements being too specific or too vague
Joint Application Design (JAD) Important Roles
Facilitatorsets the meeting agenda and guides the discussion
Scribeassist the facilitator by recording notes, making copies, etc.
Project team, users, and management
Joint Application Design (JAD) Setting
U-Shaped seatingAway from distractionsWhiteboard/flip chartPrototyping toolse-JAD
JAD Meeting Room
JPEG Figure 5-5 Goes Here
The JAD Session
Tend to last 5 to 10 days over a three week periodPrepare questions as with interviewsFormal agenda and groundrulesFacilitator activities
Keep session on trackHelp with technical terms and jargonRecord group inputHelp resolve issues
Post-session follow-up
Post JAD Follow-up
Postsession report is prepared and circulated among session attendeesThe report should be completed approximately a week to two after the JAD session
Managing Problems in JAD Sessions
Reducing dominationEncouraging non-contributorsSide discussionsAgenda merry-go-roundViolent agreementUnresolved conflictTrue conflictUse humor
Questionnaires
A set of written questions, often sent to a large number of peopleMay be paper-based or electronicSelect participants using samples of the populationDesign the questions for clarity and ease of analysisAdminister the questionnaire and take steps to get a good response rateQuestionnaire follow-up report
Questionnaire Steps
Selecting participantsUsing samples of the population
Designing the questionnaireCareful question selection
Administering the questionnaireWorking to get good response rate
Questionnaire follow-upSend results to participants
Good Questionaire Design• Begin with nonthreatening and interesting
questions.• Group items into logically coherent
sections.• Do not put important items at the very
end of the questionnaire.• Do not crowd a page with too many
items.• Avoid abbreviations.• Avoid biased or suggestive items or
terms.• Number questions to avoid confusion.• Pretest the questionnaire to identify
confusing questions.• Provide anonymity to respondents.
Document Analysis
Study of existing material describing the current systemForms, reports, policy manuals, organization charts describe the formal systemLook for the informal system in user additions to forms/report and unused form/report elementsUser changes to existing forms/reports or non-use of existing forms/reports suggest the system needs modification
Document Analysis
Provides clues about existing “as-is” systemTypical documents
FormsReportsPolicy manuals
Look for user additions to formsLook for unused form elements
Observation
Watch processes being performedUsers/managers often don’t accurately recall everything they doChecks validity of information gathered other waysBe aware that behaviors change when people are watchedBe unobtrusiveIdentify peak and lull periods
Observation
Users/managers often don’t remember everything they doChecks validity of information gathered other waysBehaviors change when people are watchedCareful not to ignore periodic activities
Weekly … Monthly … Annual
Selecting the Appropriate Techniques