Lesson Objectives

1. SA Capstone Requirements and DesignWeek 2SYST36367Winter 2013Instructors: Jerry Kotuba & Joe Varrasso

2. Lesson Objectives • SWOT Analysis • Project Feasibility (Technical, Operational, Economic, Schedule) • Project Scope and Constraints • Identifying Roles & Assigning Responsibilities • Stakeholders • Mission Statements • System Architecture • Capstone Development Methodology • Deliverable 1 (Project Proposal) due NEXT WEEK!

3. SWOT Analysis • SWOT stands for: • Strengths • Weaknesses • Opportunities • Threats • Normally used during Systems Planning Phase as part of a Preliminary Investigation Report (or Project Proposal) before the Systems Analysis Phase • Great technique to for many types of analysis including to: • Assess the status of a business or product • Assess the business case for upgrading an existing system • Identify elements of the existing system that should be preserved

4. Strategic Planning – A Framework for IT Systems Development • Strategic Planning Overview • SWOT analysis *From: Systems Analysis and Design, Ninth Edition, Gary B. Shelly & Harry J. Rosenblatt, Course Technology, CENGAGE Learning, 2012

5. SWOT Exercise • Perform a SWOT Analysis on the iPhone 5 with your Capstone Group

6. StakeholdersWho do you involve and talk to? • Stakeholders– persons who have an interest in the successful implementation of the system • Internal Stakeholders– persons within the organization • External stakeholders –persons outside the organization • Operational stakeholders –persons who regularly interact with the system • Executive stakeholders– persons who don’t directly interact, but use the information or have financial interest Systems Analysis and Design in a Changing World, 6th Edition

7. Stakeholdersof a comprehensive accounting system for public company Systems Analysis and Design in a Changing World, 6th Edition

8. Project Feasibility & Risks • Another key aspect of the Systems Planning Phase is to assess the Feasibility and Risks of the project since: • There is no point proceeding with a project if the project is not feasible! • It is important to identify risks early on so that they can be addressed! • The prototyping work later in this course is allocated for: • Completing a UI Prototype • Addressing any risks • Please focus your development efforts in this course on these two areas as by Semester 6 all risks should have been identified and addressed! • As in industry, we always want to avoid a situation where stakeholders are asking: “Why didn’t you tell me about this risk earlier?”

9. Project Feasibility & Risks • The four main components of Feasibility & Risk are: • Technical Feasibility & Risks • Example: Can a large passenger plane fly across Canada on a liter of fuel? • Operational Feasibility & Risks • Do the existing staff support the goals of the project? Do they have the technical skills to operate and maintain the new system? • Economic Feasibility & Risks • Is the Total Cost of Ownership (TCO) of the project within the budgetary constraints of the organization? Do the Tangible and Intangible benefits of the project justify the cost of the project? • Schedule (Resource) Feasibility & Risks • Have you identified the critical path of the project? What tasks or resources are on this path? • Example: Can the project be completed before the holiday buying season? • Note that areas of the project that you assess for feasibility and decide are feasible still often represent a risk for the project

10. Feasibility Exercise • In your Capstone Groups, identify at least three different reasons why a project may not be feasible from each category

11. Project Scope and Constraints • It is important to clearly define the scope and constraints of the system during the early stages of a project • Present versus future (ie. required for version 1.0?) • Internal versus external (ie. within the organization?) • Mandatory versus desirable (ex. government regulation) • Defining your project’s scope and constraints should help with your System Vision! • Possible constraints: • Platform portability • Interface with existing systems • Reuse existing components • Product support features • Government regulations *Adapted from: Systems Analysis and Design, Ninth Edition, Gary B. Shelly & Harry J. Rosenblatt, Course Technology, CENGAGE Learning, 2012

12. Identify Team Roles & Assign Responsibilities • Many projects fail because roles of team members are NOT clearly identified and/or properly assigned • Clear roles and responsibilities can help with personal accountability and avoid the dreaded “finger pointing” or “blame game”. • Recommended Steps: • Identify the required roles for the project • Clearly identify the responsibilities for each role • Determine the level of effort required for each role • Assess the skills and interests of each group member • Assign clear roles of roughly equal effort to each group member • Designate a “backup” or “shadow” for each role who is ready to assist and/or take over from the “lead” should the need arise • Reassess roles & responsibilities during the project to ensure fairness and job satisfaction

13. Mission Statement • An organization’s mission statement can be a big factor in project selection. • Organizations will often ask: “How will this project help us to achieve our mission” when deciding whether to proceed with a project • Your Capstone Group should also have a mission! • Google’s Mission is: “Google’s mission is to organize the world’s information and make it universally accessible and useful.” [1] • Microsoft’s Mission is: “At Microsoft, our mission and values are to help people and businesses throughout the world realize their full potential.” [2] • Sheridan’s Vision, Values, and Mission Statement can be found here: • http://www.sheridancollege.ca/about%20sheridan/sheridan%20at%20a%20glance/general%20information/vision%20-%20values%20and%20mission%20statement.aspx • "Company -“ Google ." Google. N.p., n.d. Web. 10 Jan. 2013. <http://www.google.ca/about/company/>. • "About Microsoft: Your Potential. Our Passion.." Microsoft Corporation. N.p., n.d. Web. 10 Jan. 2013. <http://www.microsoft.com/about/en/us/default.aspx>.

14. System Architecture Diagram-Examples [1]

15. System Architecture Diagram-Examples [2]

16. System Architecture Diagram-Examples [3]

17. System Architecture Diagram-Examples [4]

18. Development Methodologies • Over the past decade there has been a rapid rise in Agile Development Methodologies (Extreme Programming, Scrum, Unified Process, etc.) • The rise in Agile Development has brought about many positive changes including: • Greater involvement of the customer • Iterative Development which provides intermediate milestones that the customer can test and provide feedback on • Test Driven Development • Continuous Integration • Avoiding the all too common scenario of after years of development the customer saying: “But that’s not what I wanted!”

19. Development Methodologies • However, with the rise of Agile Development Methodologies it has also become more common for teams to think that: Systems Planning, Requirements Gathering and Software Architecture Design can wait till the later stages of the project • Please note that the development methodology used in the SA Capstone most closely models the “Disciplined Agile Delivery”[1] (DAD) model which is a hybrid approach adopting best processes from a variety of models. • “It includes a full range of practices. This includes initial requirements and architecture envisioning at the beginning of the project to increase the chance of building the right product in the right manner …”[1] [1] Disciplined Agile Delivery (DAD):The Foundation for Scaling Agile, Scott W. Ambler, 2012, IBM Corporation

20. DAD Development Methodology [1] Disciplined Agile Delivery (DAD):The Foundation for Scaling Agile, Scott W. Ambler, 2012, IBM Corporation

21. DAD Inception Phase [1] Disciplined Agile Delivery (DAD):The Foundation for Scaling Agile, Scott W. Ambler, 2012, IBM Corporation

22. Capstone Development Methodology • The first half of this course roughly corresponds to the Inception Phase of the DAD model • The second half of this course you will complete the first iteration of the Construction Phase which focuses on the UI Prototype (User-Centered Design) and Risk Mitigation • By the end of this course you should have achieved Stakeholder Consensus and have a Proven Architecture as shown in the DAD Lifecyle [1] • During semester 6, each group will go through several iterations of the Construction Phase before entering the Transition (Release) Phase and ending up with “Delighted Stakeholders” [1] [1] Disciplined Agile Delivery (DAD):The Foundation for Scaling Agile, Scott W. Ambler, 2012, IBM Corporation

23. Deliverable 1 (Project Proposal) • Let’s review Deliverable 1 together which is due: NEXT WEEK! • For detailed instructions and a link to the rubric please visit: http://sacapstone.wikidot.com/deliverable1instructions

24. Group Meetings • Please break into your Capstone Groups to plan and work on Deliverable 1! • We will be meeting with each group today to assess your progress and provide some advice