1. Systems Analysis and Design

2. Systems Development Life Cycle (SDLC) Systems Analysis Systems Design Programming Testing Conversion On-going maintenance

3. Systems Analysis  Attempts to answer the following questions  What is the project and why is it being undertaken?  What are the challenges we are trying to address ?  What is our target state and how does it differ from today ?  Who are the customers, their challenges, their requirements, and their expectations ?  What are the risks to the project ?

4. Feasibility Technical Feasibility –Addresses hardware, software, and technical resource Economic Feasibility –Do the benefits outweigh the costs Operational Feasibility –Does the proposed solution fit with the existing organizational framework

5. Keys to Good Systems Analysis Asking the right questions Being succinct, don’t waste client’s time Probe to determine driving forces behind the justification of a project  Ensure you capture the FULL Business perspective

6. Common Pitfalls in Systems Analysis Poorly captured requirements Focusing too early on a technical solution Not clearly understanding who the influential clients are Underestimating the degree of change that is tolerable to the organization

7. Systems Analysis as it Relates to Your Case Study Will determine : –Project Objectives –Business Scope –System Scope

8. Systems Design Defines all of the technical requirements of the application Should be complete to allow programmers to take the technical specifications and develop the necessary programs Defines the logical and physical design of : –The work flow –The programs –The data –Hardware required –Controls

9. Logical Design Describes: –Inputs –Outputs –Processes –Data Models –Controls Case tools utilized –Entity/Relationship diagramming tools –Data modeling tools

10. Inputs Where does the data originate from How will the data enter the system When is the data needed –Time frames Where does the data go after inputting

11. Outputs What medium will be used for the output? What is the time frame for the output? What will be included in the output? What is the format of the output?

12. Processing Defines the following : What are the program modules ? What computations will be required ? What areas of the organization are affected by the application ? What activities are performed ? Who performs the activities ? How often are the activities performed ?

13. Data Models Defines the relationships between the data components –Students are related to classes –Classes are related to a professor –Classes are related to classrooms File organization and design Data storage and retrieval requirements Record specifications

14. Controls Data formatting –What are the valid characters allowed –How can you minimize the possibility for errors Security

15. Systems Design as it Relates to Your Case Study Will determine : –Your Entity-Relationship Diagram –The Logical Design of your Tables –Quantitative Requirements Use boxes to show each Entity on your E/R Diagram Use 1 & M’s to indicate relationships

16. Milestone-Based Development Framework

17. Challenges Associated with the Current Methodology Project risk is rarely investigated & addressed before estimates are provided Schedule and/or Scope Slippage Customer Dissatisfaction Demoralized Staff Loss of Image

18. Risk Sources and Consequences Sources Consequences Poorly Defined Mission and Goals Deliverables not understood and agreed to by ALL interested parties Changes to the business and/or competitive environment Personnel changes New Technologies Cost Overruns Schedule and Scope Slippage Inadequate Functionality Customer Dissatisfaction Demoralized Staff Loss of Image

19. Proposed Solution Begin using a Milestone-Based Development Framework that reduces overall project risk, enhances customer satisfaction, enhances user performance, promotes team concepts, and avoids scope and schedule slippage by effectively embracing smaller, more manageable milestones throughout the project’s life

20. Development Framework Overview Goals of the Framework  Greater customer satisfaction  Enhanced user performance  Delivery to specification based on user requirements  Delivery within project constraints  All known issues are addressed  Smooth deployment and ongoing management

21. Development Framework Overview Guiding Principles :  Minimize uncertainty through effective risk reduction  Establish fixed schedules  Utilize small teams working in parallel with frequent synchronization points  Break large projects into manageable parts that can be delivered in a few months  Avoid feature creep  Use proof-of-concept prototyping  Apply zero-defect mindset Apply no-blame milestone reviews

22. Development Framework Overview The framework consists of 4 distinct milestones :  Vision/Scope Approval  Function Design Specification  Scope Complete/First Use  Release  The customer only commits time and resources to the next phase

23. Development Framework Overview The customer only commits time and resources to the next phase At the beginning of the project, the customer only commit time and resources to complete the Vision/Scope Approval milestone If the Vision/Scope is approved, the customer only commits to the completion of the Functional Design Specification milestone If the Functional Design Specification is approved, the customer commits to the completion of the project as defined by the Functional Specification

24. Vision/Scope Approval Milestone Role of the Vision / Scope Milestone  Defines the direction for the project team  Encourages explicit up-front discussion of project goals, priorities and constraints  Sets the customer’s expectations  Provides the basis for an initial assessment of project’s risk  Provides criteria for tailoring the development process to the characteristics of the project, team, and the organization  Provides a basis for estimating the effort required to produce a Functional Specification for what is to be built, as well as for deciding if a Functional Specification is required at all

25. Vision/Scope Approval Milestone Includes: Long-range vision  Shorter-range scope  A Proactive Risk Management Plan  Issues and Bug Database  Assumptions & Constraints  Project Resources Time and effort required for the planning phase (Functional Design Specification)

26. Functional Design Specification Approval Milestone Role of the Functional Specification  Captures a definition of WHAT the system will do  Sets customer expectations of what will be delivered in the target release baseline  Ensures the entire team is building the same system :  Development understands what it has committed to build  Program Management is promising / marketing the same system that development is building  Program Management can track progress against a known target set of functionality  Provides a structure within which the team can evaluate implementation options and make implementation decisions early in the development process  Specifies interfaces with other systems and/or processes  Provides a context for evaluating change requests  Provides a context for making tradeoff decisions should target dates prove unachievable

27. Functional Design Specification Approval Includes:  Project Deliverables are agreed to  Features and priorities  Risks are updated  Deployment date  Business requirements completed  Functional specification  Project Plan Project Schedule Test Specifications

28. Scope Complete / First Use Milestone Role of the Development/Scope Complete/First Use Milestone  All Features are built to specification  Utilization and evaluation of the product even if testing is not completed  Customers using the product under Beta conditions  Deployment of infrastructure required for first use  Zero defects are allowed  Deployment plans are produced

29. Release Milestone Role of the Deployment Milestone agreement  Product stability is assured and all issues are resolved  Customer acceptance  Long-term management and support is defined and agreed  Team focus is adjusted for next phase or release

30. Team Model Throughout the process, the team model is embraced with team members and roles clearly defined. The team consists of:  Product Management  Articulates the project’s vision to all interested parties  Acquires and quantifies customer requirements  Develops and maintains business case  Manages customer expectations  Program Management  Develops the Functional Specification  Facilitates communication and negotiation within the team  Develops and maintains the project schedule, project plan, risk management plan, and reports project status

31. Team Model  Development  Builds a product that meets the specification and customer expectations  Evaluates technical solutions to be acquired or utilized  User Education  Ensures every user is capable of getting the most out of the product  Delivers user performance support that enables productivity  Reduces support costs  Testing  Ensures all issues are known before release  Develops testing strategy and plans  Logistics  Ensures a smooth rollout of the product

32. Capturing the Vision / Business Objective What is our target state ? What should the world be like ? How does that differ from what it is now ? What are the key business processes ? What is the business objective ? How will the solution interact with existing applications ? How will the solution interact with external applications ? What are the business needs ?

33. How do the business processes currently satisfy these needs ? How might it do it in the future ? What activities within processes be optimized or made easier ? What degree of change will be tolerable for the organization ? What are the strengths of the current processes? What are the weaknesses ? What benefits will be received by this project ? What is motivating this project ? What tasks should be addressed in this version of the product ?

34. Conclusions / Questions?? Customers, I/T and the team knows exactly what will be delivered, when it will be delivered and at what cost Greater use of team concepts and the benefits within Dramatically reduced risk to the project Customers have greater flexibility by only committing to smaller, more manageable releases