Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Planning Phase
Focus :
Why build this system? How to structure the project?
System request with feasibility study Project Plan Identify opportunity Analyse feasibility Develop work plan Staff project Control and direct project
Analysis Phase
Focus: Primary output Steps
Who, What and Where and when for this system
System proposal Develop analysis strategy Determine business requirement Create use cases Model processes Model data
Design Phase
Focus: Primary output:
How will this system work?
System Specification Design Physical system Design architecture Design Interface Design Databases and files
Steps
Implementation Phase
Focus: Primary output:
Delivery and support of completed System
Installed System Construct System Install System Maintain System Post Implementation
Steps
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.
System Request
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.
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
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.
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 feasibility Economic feasibility Organizational 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.
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
Waterfall Development
Waterfall Strengths
Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule
Waterfall Deficiencies
All requirements must be known upfront Deliverables created for each phase are considered frozen inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)
Parallel Development
V-model
V-Shaped Strengths
Emphasize planning for verification and validation of the product in early stages of product development Each deliverable must be testable Project management can track progress by milestones Easy to use
V-Shaped Weaknesses
Does not easily handle concurrent events Does not handle iterations or phases Does not easily handle dynamic changes in requirements Does not contain risk analysis activities
System Prototyping
Prototyping Model
Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
Prototyping Strengths
Customers can see the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality
Prototyping Weaknesses
Tendency to abandon structured program development for code-and-fix development Bad reputation for quick-and-dirty methods Overall maintainability may be overlooked The customer may want the prototype delivered. Process may continue forever (scope creep)
Iterative Development
Agile SDLCs
Speed up or bypass one or more life cycle phases Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined methods
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 project Communication among teammates is done with code Life cycle and behavior of complex objects defined in test cases again in code
RAD Strengths
Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code (WYSIWYG). Uses modeling concepts to capture information about business, data, and processes.
RAD Weaknesses
Accelerated development process must give quick responses to the user Risk of never achieving closure Hard to use with legacy systems Requires a system that can be modularized Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.
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.
Learning Objectives
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
Introduction
The As-Is system is the current system and may or may not be computerized The To-Be system is the new system that is based on updated requirements The 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 isnt 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.
What is a Requirement?
A statement of what the system must do A statement of characteristics the system must have Focus is on business user needs during analysis phase Requirements will change over time as project moves from analysis to design to implementation
Requirement Types
Functional Requirements
A process the system has to perform Information the system must contain
Nonfunctional Requirements
Behavioral properties the system must have
Operational Performance Security Cultural and political
Non-functional: describes a restriction or constraint that limits our choices for constructing a solution Examples:
Paychecks distributed no more than 4 hours after initial data are read. System limits access to senior managers.
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 characteristics Browse - enable user to look through items Shop - enable user to select and purchase items Comment - enable user to submit his/her comments on items and read other users' comments on items Personalize - enable site to remember user's preferences based on previous use of the site and orders placed Registries - enable user to participate in registry (e.g., wedding, baby); enable users to search registries Wish 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.
Key purpose is to define the project scope: what is and is not to be included.
Determining Requirements
Participation by business users is essential Three techniques help users discover their needs for the new system:
Business Process Automation (BPA) Business Process Improvement (BPI) Business Process Reengineering (BPR)
Duration Analysis
Calculate time needed for each process step Calculate time needed for overall process Compare the two a large difference indicates a badly fragmented process Potential solutions:
Process integration change the process to use fewer people, each with broader responsibilities Parallelization change the process so that individual step are performed simultaneously
Activity-Based Costing
Calculate cost of each process step Consider both direct and indirect costs Identify most costly steps and focus improvement efforts on them
Benchmarking
Studying how other organizations perform the same business process Informal benchmarking
Common for customerfacing processes Interact with other business processes as if you are a customer
Outcome Analysis
Consider desirable outcomes from customers perspective Consider what the organization could enable the customer to do
Technology Analysis
Analysts list important and interesting technologies Managers list important and interesting technologies The 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 eliminated Use force-fit to test all possibilities
Comparing Analysis Techniques Potential business value Project cost Breadth of analysis Risk
Project Characteristics
Learning Objectives
Understand when to use and gather requirement using various requirement analysis technique Understand when to use each requirement gathering techniques
Mini Case 1
Problem analysis and benchmarking would be feasible strategies to employ in this situation. This is a problem with a rather narrow scopethe 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 systems requirements.
Recognize the important side effects of the requirement gathering process Carefully determine who is included in the requirement gathering process Respect the time constraint that you are asking the participants to make.
Selecting Interviewees
Based on information needed Often good to get different perspectives
Managers Users Ideally, all key stakeholders
Types of Questions
Types of Questions Closed-Ended Questions * Examples 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? Why? Can you give me an example? Can you explain that in a bit more detail?
Probing Questions
* * *
Structured interview
More specific information
Questioning Strategies
Post-Interview Follow-Up
Prepare interview notes Prepare interview report Look for gaps and new questions
Interview Report
INTERVIEW REPORT
Scribe
assist the facilitator by recording notes, making copies, etc.
Postsession report is prepared and circulated among session attendees The report should be completed approximately a week to two after the JAD session
Questionnaires
A set of written questions, often sent to a large number of people May be paper-based or electronic Select participants using samples of the population Design the questions for clarity and ease of analysis Administer the questionnaire and take steps to get a good response rate Questionnaire follow-up report
Questionnaire Steps
Selecting participants Using samples of the population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow-up Send results to participants
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 system Forms, reports, policy manuals, organization charts describe the formal system Look for the informal system in user additions to forms/report and unused form/report elements User changes to existing forms/reports or nonuse of existing forms/reports suggest the system needs modification
Document Analysis
Provides clues about existing as-is system Typical documents Forms Reports Policy manuals Look for user additions to forms Look for unused form elements
Observation
Watch processes being performed Users/managers often dont accurately recall everything they do Checks validity of information gathered other ways Be aware that behaviors change when people are watched Be unobtrusive Identify peak and lull periods
Observation
Users/managers often dont remember everything they do Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities Weekly Monthly Annual