CHAPTER ‘3’ Project Blastoff

Slides:



Advertisements
Similar presentations
Lecture 5: Requirements Engineering
Advertisements

5/5/2015Software Engineering Code of Ethics1 Software Engineering Code of Ethics and Professional Practice Dr. Bob Weber CEG 460 / 660 Wright State University.
Chapter 3 Project Initiation
The Australian/New Zealand Standard on Risk Management
Software Requirements The Volere Requirements Source: “Mastering the Requirements Process”, S. Robertson, J. Robertson Created by Eshcar Hilel.
Chapter 3 Project Initiation. The stages of a project  Project concept  Project proposal request  Project proposal  Project green light  Project.
The Agile vs. Waterfall Methodologies Systems Development:  the activity of creating new or modifying / enhancing existing business systems.  Objectives.
Software Evolution Planning CIS 376 Bruce R. Maxim UM-Dearborn.
SYSTEM ANALYSIS AND DESIGN
Systems Analysis and Design with UML Version 2
1 Requirements Analysis and Design Engineering Southern Methodist University CSE 7313.
S/W Project Management
Typical Software Documents with an emphasis on writing proposals.
© The McGraw-Hill Companies, An Introduction Chapter 1 Software Project Management 4 th Edition Robert Hughes and Mike Cotterell.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
BMT Sigma Capability Overview. BMT Group An international network of subsidiaries providing engineering, design and risk management consultancy Wholly.
Feasibility Study.
1.  Project: temporary endeavor to achieve some specific objectives in a defined time  Project management ◦ Dynamic process ◦ Controlled and structured.
1 Copyright Flying Kiwi Productions Inc. An Introduction to Object-Oriented Analysis Objects and UML in plain English. Chapter.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Chapter 12: Systems Investigation and Analysis. Agenda  How to Develop a CBIS?  Systems Development Life Cycle (SDLC)  Prototyping  Join Application.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
1 Activities covered by project management Feasibility study Is project technically feasible and worthwhile from a business point of view? Planning Only.
Strong9 Consulting Services, LLC 1 PMI - SVC I-80 Breakfast Roundtable Monthly Meeting Thursday, October 12, :00 am – 9:00 am.
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Project Specification part 2 BTEC National. Project boundaries or scope The boundaries or scope of a project are what the project aims to achieve. The.
Applied Software Project Management
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
12/10/15.  It is a Cross Life Cycle Activity (CLCA) that may be performed at any stage ◦ In fact, some part of it (e.g. risk analysis and management)
Systems Development Life Cycle
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Module 4: Systems Development Chapter 13: Investigation and Analysis.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
Quiz 1 Q1) Discuss briefly the main phases of the requirement process. Q2)Discuss briefly the main outcome of the Trawling for Requirements phase.
Software Requirements Engineering Session: 1 Topics: Chapters 1 – 3.
Slide 1 Systems Analysis and Design with UML Version 2.0 An Object-Oriented Approach, Second Edition Chapter 3: Project Initiation.
Writing the Requirements
Engineering Economic Analysis CHAPTER 1 1. What is Engineering Economy? Engineering economy involves the financial and economic evaluation of projects.
Short-range weather forecasts

C. What is a Feasibility report
Applying UML and Patterns
Fundamentals of Information Systems, Sixth Edition
Systems Analysis and Design in a Changing World, 4th Edition
Requirement Prioritization
Principles of Information Systems Eighth Edition
The Systems Engineering Context
PowerPoint® Slides to Accompany
CS 641 – Requirements Engineering
CS 641 – Requirements Engineering
(Additional materials)
FEASIBILITY STUDY Feasibility study is a means to check whether the proposed system is correct or not. The results of this study arte used to make decision.
REKAYASA PERANGKAT LUNAK
By Kean Tak, MSc, Lecturer at RUPP
CS 790M Project preparation (I)
Chapter 3: The Requirements Workflow
Systems analysis and design, 6th edition Dennis, wixom, and roth
Systems analysis and design, 6th edition Dennis, wixom, and roth
ELEC4011 Ethics & Electrical Engineering Practice Hugh Outhred
Design and Implementation
Project Management Process Groups
Viable Proposals: Planning & Securing Buy-in
Chapter 4 Inception CS John Cole.
Project Management Concepts May 5th, 2016
Robertson & Robertson: Chapter 2 Software Specification Lecture 10
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

CHAPTER ‘3’ Project Blastoff Dr. Ahmad F. Shubita

Blastoff Deliverables Goal/ Purpose of the project – short, measurable statement The client – who is the product being built for? The customer – who is going to buy the product? The stakeholders – people with interest The users – who is going to operate the product? Constraints – design, time or money Names – terminology Scope of the work – boundaries of project/product Estimated costs – effort, money The risks – risk analysis

Project Blastoff Activities

IceBreaker – Case Study IceBreaker is a case study we’ll use to demonstrate the requirements process. It uses a variety of data to predict exactly when ice will form on roadways , and it uses these predictions to schedule trucks to treat the roads with deicing material (a salt compound) before the roads become dangerous. The IceBreaker case study uses subject matter knowledge from the many weather/ice forecasting and road de-icing systems, and other products produced by Vaisala (U.K.) 

Aspects of a Goal Purpose – what does it do? Advantage – business advantage Measurement – how to measure Feasible – can product achieve measure? Achievable – can organization build?

Product Purpose Purpose: To accurately forecast freezing times and dispatch de-icing trucks. Advantage: To reduce road accidents by forecasting icy road conditions. Measurement: Accidents attributed to ice shall be no more than 15% of the total number of accidents during winter. Supporting Materials: Thornes, J.E., 1992: Cost-Effective Snow and Ice Control for the Nineties. …

Product Purpose Purpose: To save money on winter road maintenance costs. Advantage: Reduced de-icing and road maintenance costs. Measurement : The cost of de-icing shall be reduced by 25% of the current cost of road treatment, and damage to roads from ice shall be reduced by 50%.

Product Purpose Purpose : To reduce damage to the environment by unnecessary application of de-icing compounds. Measurement: The amount of de-icing chemicals needed to de-ice the council’s roads shall be reduced by 50% Supporting Materials: Thornes, J.E., Salt of the Earth. Surveyor Magazine …

Clients & Customers Client is the person who pays for the development. Customer is the person(s) that pay for the product once it is developed.

Who’s Paying for This? Know the client and your customer Know what they want Understand the customer’s problems Understand the client’s objectives Know what is acceptable and unacceptable to the client and customer

Users Persons who ultimately operate the product In-house products: people that work for your client External products: user & customer usually are the same person

Roles of Users What are the jobs of the people who might use your product? What other roles might people have? Where will people be when using your product? What are the nationalities of the people who might use your product? Are there organizations that might use your product? Other considerations: People with disabilities Non-readers People with reading glasses

Stakeholders & Consultants Public Opinion Government Special Interest Groups Technical Experts Cultural Interests Adjacent Systems Management Business Subject Matter Developers Inspectors Legal Professional Bodies

Requirements Constraints Solutions Constraints Allowable Designs Prepackaged Solutions – Commercial off-the-shelf applications Partner applications Project Constraints Financial constraints Time constraints

Naming Terminology is extremely important to a project Example: Weather Station – a collection of hardware capable of collecting and transmitting road temperature, air temperature, humidity and precipitation readings. Weather stations are installed in eight locations in Northumberland.

Setting The Scope Deciding how much work will be done. Should contain the product purpose and other constraints. Also should address the domains of interest is a subject matter area. Sets the Work Scope

Domains of interest – Case Study Roads Weather Scheduling Trucking

The Role of Adjacent Systems The adjacent systems are those pieces of work that supply your work with information or that receive information and services from your work An adjacent system might be an organization, an individual, a computer system or some other piece of technology, or a combination of any of these. 6/30/2018

Types of Adjacent Systems Active Adjacent Systems: usually humans Independent Adjacent Systems it is some external body to your work, e.g. other company, government department, example: weather station Supportive Adjacent Systems Can be relied onto and behave predictably ( computerized systems), example: thermal mapping supplier. 6/30/2018

Adjacent systems - Case Study Weather forecasting service Weather station Map supplier Road engineering Truck station

Work Context

The Risks Project related risks Inadequate measurement Excessive schedule pressure Inaccurate cost estimating Low quality Low productivity

The Risks Requirements related risks The absence of clear & measurable purpose for the product Lack of client involvement Lack of stakeholder involvement Little or no agreement on requirements No measurements put on requirements Rapidly changing requirements New or unknown business area with uncertain needs

Go/No-go Decision Is the product Goals/purpose clear? Is it measurable and viable? Is it possible to achieve the objectives of the project? Can you reach agreement on the context of the work? Does the high portability/impact of the risks make the project feasible? Is the cost reasonable for the product’s benefit? Are the stakeholders willing to be involved? Do you have sufficient justification to invest in the project? Do you have enough reasons not to invest in the project? Is there any further investigation that you should do before pressing the button to start the project?

Exercise “In a voting system, the candidate can apply for an election to become a candidate, the candidate then can register in the system to enter his detailed information. The candidate also can modify his information at any time. When voting is open, the voter can register on the system and perform voting. The candidate also can register and perform voting. Both candidate and voter need to login as voter to perform voting.” Define two Purposes of the given system. Set the scope of the work by sketching the work context diagram(Scope Diagram) of the voting system.