CIS 454: Exam 1

pert weighted average

(optimistic estimate + (4 * most likely estimate) + pessimistic estimate) / 6

Scrum's Values

Focus Courage Openness Commitment Respect

Operational Requirements

Technical Environment Special hardware, software, and network requirements imposed by business requirements System Integration The extent to which the system will operate with other systems Portability The extent to which the system will need to operate in other environments Maintainability Expected business changes to which the system should be able to adapt

disadv of agile development

- requires colocation of the development team, so can't outsource/subcontract - if not carefully managed (by definition it is not), development process can devolve into a prototyping approach that essentially becomes a "programmers gone wild" environment where solutions are hacked together - issues regarding auditability due to lack of documentation of processes

Twelve Principles of Agile Methodologies

- software is delivered early and continuously through the development process, satisfying the customer - changing requirements are embraced regardless of when they occur in the development process - working software is delivered frequently to the customer - customers and developers work together to solve the business problem - motivated individuals create solutions, provide them the tools and environment they need, and trust them to deliver - face to face communication within the development team is the most efficient and effective method of gathering requirements - primary measure of progress is working, executing software - both customers and developers should work at a pace that is sustainable. that is, the level of work could be maintained indefinitely without any worker burnout - agility is heightened through attention to both technical excellence and good design - simplicity, the avoidance of unnecessary work, is essential - self-organizing teams develop the best architectures, requirements, and designs - development teams regularly reflect on how to improve their development processes

•Special issues

-Issues that are relevant to the implementation of the system and the decision made by the committee about the project -Examples: •Government-mandated deadline for May 30 •System needed in time for the Christmas shopping season •Top-level security clearance needed by project team to work with this data

•Project sponsor

-Person who initiates the project and who serves as the primary point of contact for the business side -Example: •Several members of the Finance Department •Vice President of Marketing •IT Manager •Steering Committee Chair •CEO or CFO or CMO

•Business value

-The benefits that the system will create for the organization (normally presented in numbers/data) -Examples: •A 3% increase in sales •A 1% increase in market share •Reduction of headcount by 5 FTE employees •$200,000 cost savings from decrease in supply costs •$150,000 savings from removal of existing system

•Business requirements

-The business capabilities that the system will provide -Examples: •Provide online access to information •Capture customer demographics information •Include product search capabilities •Produce management reports Include online user support

•Business need

-The business-related reason for initiating the system -Examples: •Increase sales •Improve market share •Improve access to information •Improve customer services •Decrease product defects •Streamline supply acquisition process

Principles behind the Agile Manifesto

1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4.Business people and developers must work together daily throughout the project. 5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6.The most efficient and effective method to convey information to and within a development team is face-to-face conversation. 7.Working software is the primary measure of progress. 8.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9.Continuous attention to technical excellence and good design enhances agility. 10.Simplicity—the art of maximizing the amount of work not done—is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Timeboxing Steps

1.Set the date for system delivery 2.Prioritize the functionality that needs to be included in the system 3.Build the core of the system (the functionality ranked as most important) 4.Postpone functionality that cannot be provided within the time frame 5.Deliver the system with core functionality 6.Repeat steps 3 through 5 to add refinements and enhancements

How does each methodology compare? 1) Talk to user 2) want to be efficient or effective 3) comment

1970s: Waterfall = no, efficient (75% of systems failed), update 1 in 10 years 1980s: parallel = rarely, efficient, update 1 in 5 years 1990s: phased = yearly, effective, update 1 in 3 years 2000s: prototyping (practice runs that explain the process) = a lot, effective, update yearly throwaway prototype (design something for user to create conversation, and from that conversation, you can gather requirements. the prototype cannot be turned into the real system, so it is discarded and replaced with a new prototype. ie building something in excel, but then redoing it in SQL) = much, effective, less than every 6 months 2020s: Agile/SCRUM = weekly/daily, effective AND efficient, at most every month

extreme programming

4 core values: communication, simplicity, feedback, courage. testing and efficient coding practices are the core of XP. Code is constantly tested until all bugs are worked out

A feasibility analysis is completed and submitted with a system request to a(n) _____.

Approval committee

Project cost money, so it is important to determine when the returns will match the amount invested. This is called _____.

Break-even point

Implementation

Build the system! 1.Construct system (system is built and tested to make sure it performs as designed. testing is critical since the cost of bugs is immense. more time given to testing than writing programs) 2.Install system (installation = old system turned off, new system turned on) -Implement a training plan for the users 3.Establish a support plan (formal or informal post-implementation review as well as a systematic way for identifying major and minor changes needed for the system)

Technical Feasibility

Can we build it? •Familiarity with application -Less familiarity generates more risk •Familiarity with technology -Less familiarity generates more risk •Project size (relative for each org. large projects for a small org could be considered a small project for a large org) -Large projects have more risk •Compatibility Difficult integration increases the risk

Design

How will we build the system? how system will operate in terms of hardware, software, network infrastructure, user interface, forms/reports, programs, databases, files 1.Develop a design strategy (make your own system, outsource, or buy a package) 2.Design architecture and interfaces (hardware, software, network infrastructure. interface design = how users move through the system) 3.Develop databases and file specifications (defines what data will be stored and where) 4.Develop the program design (defines the programs that need to be written and exactly what each program will do)

Organizational Feasibility

If we build it, will they come? •Stakeholder Analysis-identify stakeholders and the role each plays -Project champion(s) -Senior management -Users -Others •Is the project strategically aligned with the business?

A group of people so strongly knit that the whole is greater than the sum of the parts is called a(n) _____.

Jelled team

Nonfunctional Requirements

Operational = system should be able to fit in a pocket or purse, system should integrate into existing system Performance = interactions should be 2 seconds, updates every 15 minutes Security = only direct managers can see personnel records of staff, customers can see order history during business hours Cultural/Political = system should distinguish US and UK money, system should comply with insurance standards

Estimating Project Timeframes

Planning = 15% Analysis = 20% Design = 35% Implementation = 30%

4 phases of SDLC

Planning, Analysis, Design, Implementation

Scrum Artefacts

Product Backlog Sprint Backlog Burndown Chart Impediment Backlog

Three Scrum Roles

Product Owner (determines what needs to be done to draw out the most value. •manages the product (and return on investment)) Team Member (manages itself. are the ones who accomplish tasks set by the product owner) Scrum Master (manages the process. makes sure the process is being followed by removing impediments to the team and helping the product owner stay on track)

Scrum Roles & People

Responsibilities of the traditional project manager are divided over the three roles •There are no appointed leaders of the Scrum Team beyond the Product Owner and ScrumMaster •Self-organized teams are highly disciplined, given full autonomy and carry correspondingly greater responsibility for delivery. •Self-organized teams are encouraged to take reasonable risks and to learn through failure and self-reflection •Self-organized teams are encouraged to take ownership

Economic Feasibility

Should we build it? •Development costs (down payment on a car) •Annual operating costs (loan on car you bought, insurance, gas, etc.) •Annual benefits (cost savings and revenues) (saving money on gas thanks to new car) •Intangible costs and benefits (convenience of owning a car)

Performance Requirements

Speed Time within which the system must perform its function Capacity Total and peak number of users and the volume of data expected Availability and reliability Extent to which the system will be available to the users and the permissible failure rate due to errors

Security Requirements

System value estimates Estimated business value of the system and its data Access control Limitations on who can access what data Encryption and authentication Defines what data will be encrypted where and whether authentication will be needed for user access Virus control Controls to limit viruses

Scrum Structure (Meetings)

The sprint is the heartbeat of the Scrum cycle. Most Scrum teams choose two, three or four weeks as their sprint duration. Each day during the sprint the team holds a daily Scrum meeting. Every meeting in Scrum is strictly time-boxed. This means that is has a maximum duration. Sprint Planning 1 & 2 at the start Sprint Review and Sprint Retrospective at the end

Setting a fixed deadline for a project and delivering the system by that deadline is called _____.

Timeboxing

Analysis

WHO will use the system What should the system do for us? Where and when will it be used? 1.Develop analysis strategy (analysis of current system aka as-is system and its problems and then ways to design a new system aka to-be system) 2.Gather requirements (through interviews/questionnaires. analyzing this info with additional input leads to the development of a concept for a new system, which is used to make analysis models that will show how the business will operate if new system is developed) 3.Develop a system proposal (culmination of analyses, system concept, and models. presented to the project sponsor and other key decision makers who decide whether to give green light or not)

Planning

Why should we build this system? fundamental process of understanding WHY an IS should be built and determining how the project team will go about building it 1.Project Initiation -Develop a system request -Conduct a feasibility analysis - system's business value to the org is identified 2.Project Management -Develop work plan -Staff the project Control and direct the project - Deliverable = project plan (how the project team will go about developing the system)

system request

a document that describes the business reasons for building a system and the value that the system is expected to provide

workplan

a dynamic schedule that records and keeps track of all the tasks that need to be accomplished over the course of the project created when the project manager has a general idea of the functionality and effort for the project

work breakdown structure (wbs)

a list of tasks hierarchically numbered number of tasks and level of detail depend on the complexity and size of the project at minimum, wbs must include the duration of the task, the current status of the task (open/complete) and the task dependencies, which occur when one task cannot be performed until another task is completed

task

a unit of work that will be performed by a member or members of the dev team, such as feasibility analysis

cost-benefit analysis

another name for economic feasibility identifies the financial risk associated with the project (SHOULD we build the system) page 51 components include: Return on investment (ROI), breakeven point, present value (PV), net present value (NPV)

parallel development

attempts to address the problem of long delays between the analysis phase and the delivery of the system. instead of design -> implementation, it performs a general design for the whole system and then divides the project into a series of distinct subprojects that can be designed and implemented in parallel. when the subprojects are complete, they are all integrated together and delivered adv: - reduce the time to deliver a system (less chance of changes in the business environment causing rework) disadv: - sometimes subprojects are not independent. design decisions made in one subproject can affect another, and the end of the project can require significant integration efforts

phased development

breaks an overall system into a series of versions that are developed sequentially analysis phase identifies the overall system concept, and the project team/users/sponsor categorize the requirements into a series of versions. most important and fundamental requirements are bundled into the first version of the system. each version has an analysis, design, and implementation step. once one version is completed, you move on to the next version until it is complete. adv: - quickly getting a useful system into the hands of the users (does not need to be completed to be delivered, unlike waterfall/parallel) - because users can get it sooner, they are able to identify additional requirements sooner disadv: - although able to be in user hands sooner, does not perform all the functions the users needs at first - users work with systems that are intentionally incomplete. critical to identify the most important and useful features and include them in the first version and manager expectations

building a an IS is similar to

building a house: 1) start with basic idea of house 2) expand upon the ideas with drawings and refine until customer gets what they want 3) transfer drawings into blueprint and add even more detail 4) build the house following the blueprints

Project Team Roles

business analyst systems anayst infrastructure analyst change management analyst project manager

return on investment (roi)

calculation listed somewhere on the spreadsheet that measures the amount of money an organization receives in return for the money it spends drawback = considers only the end points of the investment, not the cash flow in between

champion

high level, non-information systems executive who is usually the project sponsor who created the system request

gantt chart

horizontal bar that shows the same task information as the project wbs but in a graphical way

stakeholder analysis

how a stakeholder (person/group/org) can affect or will be affected by a new system

SCRUM

most chaotic methodology. teams are self-organized and self-directed, no team leaders. once a sprint begins (sprints are 30 days), teams do not consider any additional requirements. at the end of the sprint, a project is delivered, and the results impact how the next sprint should proceed.

scope creep

occurs when new requirements are added to the project after the original project scope was defined and frozen most common reason for schedule and cost overruns

waterfall development

original design methodology. proceed from one phase to the next adv: - identifies system requirements long before programming begins - minimizes changes to the requirements as project proceeds disadv: - design must be completely specified before programming - long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system

strategic alignment

the fit between the project and the business strategy greater the alignment, the less risky the project will be from an organizational feasibility perspective

system prototyping

performs the analysis, design, and implementation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed. basics of analysis and design are performed, and work immediately begins on a system prototype, quick program that has minimal amount of features. each prototype is used to refine the next prototype, adding or changing features. this process continues until everyone reaches an agreement on whether a prototype has enough functionality, where it is then refined until it becomes the final system. adv: - very quickly provides a system with which the users can interact, even if it is not ready for widespread organizational use at first - reassures users that the project team is working on the system (no long delays) - helps to more quickly refine real requirements disadv: - fast paced system releases challenge attempts to conduct careful, methodical analysis - undergoes so many significant changes that older prototypes become obsolete. can cause issues when fundamental issues are not discovered until late into the process (like building a car but not leaving space for an engine)

process and deliverables

planning -> project plan analysis -> system proposal design -> system specification implementation -> new system and maintenance plan

Types of methodologies

process centered data centered object-oriented = uses both processes and data

Systems development life cycle (SDLC)

process of understanding how an information system can support business needs by designing a system, building it, and delivering it to users GRADUAL refinement

Pert Chart

program evaluation and review technique (pert) is a network analysis technique that can be used when the individual task estimates are fairly uncertain combines 3 estimates (optimistic, most likely, and pessimistic) into a weighted average •Used to communicate task dependencies •Allows easier visualization of tasks on a critical path

throwaway prototyping

similar to system prototyping, except they are done at a different point in the SDLC. Analysis phase is very thorough in order to build a design prototype (not a working system, only represents a part of the system that still needs refinement. used to understand issues under consideration). the design prototype is built and refined repeatedly to confirm the important issues and minimize risk before the actual system is built. once design prototype is finalized, the rest are thrown away as it heads into implementation adv: - balances the benefits of well thought out analysis and design phases with the adv of using prototypes to refine key issues before a system is built - produces more stable and reliable systems than system proto disadv: - can take longer to deliver the final system as compared to system prototyping

critical success factor for project management

start with a realistic assessment of the work that needs to be accomplished and then manage the project according to that assessment

portfolio management

takes into consideration the different kinds of projects that exist in an org - large/small, high/low risk, strategic/tactical a good project portfolio has the most appropriate mix of projects for the org's needs

key person in SDLC

the analyst analyzes the business situation, identifies opportunities for improvements, and designs an information system to implement them

project management

the process of planning and controlling the development of a system within a specified time frame at a minimum cost with the right functionality (cost, schedule, performance)

primary objective of systems analyst

to create value for the organization NOT to create a wonderful system goal is NOT to acquire a tool, but to enable the organization to perform work better so that it can earn greater profits or serve its constituents more effectively

Defining a Requirement

•A statement of what the system must do or what characteristic it must have •During analysis, requirements are written from the perspective of the businessperson •Two kinds of requirements: -Functional (calculations, data manipulation) -Nonfunctional

Developing Work Plans

•A work plan, is a dynamic schedule that records and keeps track of all tasks to be accomplished over the course of the project •Created after a project manager has a general idea of the project's size and rough schedule •The work plan is usually the main item in a project management software application

Motivational Don'ts

•Assign unrealistic deadlines •Ignore good efforts •Create a low-quality product •Give everyone on the project a raise •Make an important decision without the team's input Maintain poor working conditions

Object-Oriented Analysis & Design

•Attempt to balance emphasis on data and process •Uses Unified Modeling Language (UML) •Characteristics of OOAD: -Use-case Driven -Architecture Centric ( -Iterative and Incremental

Conflict Avoidance Strategies

•Clearly define roles and project plans •Make sure the team understands how the project is important to the organization •Develop detailed operating procedures and communicate these to the team members •Develop a project charter •Develop schedule commitments ahead of time •Forecast other priorities and their possible impact on project

CASE Tools

•Computer-Aided Software Engineering (CASE) tools automate some or all of the development process •Not a silver bullet, but advantages include: -Reduced maintenance costs -Improve software quality -Enforce discipline -Some project teams even use CASE to assess the magnitude of changes to the project

Successful Projects depend on 3 factors

•Cost At project completion, no more money has been spent than was originally allocated •Schedule The project is delivered no later than the original delivery date •Performance When delivered, the project has all features and functionality that were originally required of it

Sprint Review

•Demo the new features and inspect the product •How is the design going? •Gather feedback from "the whole world"

UML Behavior Diagrams

•Depict the dynamic relationships among the instances or objects that represent the business information system •Activity* (we will learn in the CIS curriculum) •Sequence •Communication •Interaction overview •Timing •Behavior state machine •Protocol state machine •Use-case diagrams*(we will learn in the CIS curriculum)

Sprint Burndown Chart

•Designed to graphically display the progress of the team in stories or tasks of the Sprint •Easier to determine that the team will meet its commitment at the end of the sprint

Staffing the Project

•Determine average number of people needed -Divide total person-months of effort by the optimal schedule -Adding more people will not reduce schedule •Create a staffing plan -Roles required for the project -Reporting structure

ScrumMaster Responsibilities

•Empowering and shepherding the team •Removing impediments •Keeping the process moving •Socializing Scrum to the greater organization

Team Responsibilities

•Estimating size of backlog items •Committing to increments of deliverable software - and delivering it •Tracking own progress •Is self-organizing—but accountable to the Product Owner for delivering as promised Team members can be developers, testers, analysts, architects, writers, designers and even users. The team is cross-functional, which means that between all its members they possess sufficient skills to do the work. There is no dictated leadership hierarchy within the team members.

How Not to Select a Project

•First in, first out •Political clout of project inventor •Squeaky wheel getting the grease •Any other method that does not involve a deliberate course of action analysis A recent analysis found that between 2% and 15% of projects taken on by IT departments are not strategic to the business.

Sprint Retrospective

•Follows the Sprint Review •Only members of the Scrum Team •Focus on process •How is the Scrum team working together •Assess skills •Assess software practices and tools •Assume that everyone on the team did their best, but do we need different skills, practices or tools to succeed?

Documentation

•Good documentation happens up front -Documentation that occurs only at the tail end of a project/phase is not very useful •Project binder(s) are best practices containing -All internal communications (e.g. minutes from status meetings) -Written standards -Letters to and from the business users -Deliverables from each task

Feasibility Analysis

•Guides the organization in determining whether to proceed with a project •Identifies the project's risks that must be addressed if the project is approved To be feasible, project must meet these 3 components: •Major components: -Technical feasibility -Economic feasibility - Organizational feasibility do tech, eco, org in that order

Manifesto for Agile Software Development

•Individuals and interactions over processes and tools (team members need to trust each other and communicate to succeed) •Working software over comprehensive documentation (there must be a working product by the end of the sprint. documentation is important, but that can wait) •Customer collaboration over contract negotiation (product owner's job to build a rich collaboration with their team. they determine what needs to be done first) •Responding to change over following a plan (must be flexible and adapt to changes, even if it goes off plan)

Product Backlog

•List of work items that need to be done over time to complete the product •Items may be added to the backlog by anyone •A living document that requires "grooming" •Set of Stories written on 4 X 6 cards (user perspective)

Product Burndown Chart

•Measures the rate of delivery of a stream of running, tested, features over time of the Product

Sprint Planning - Part 1 (Requirements Gathering)

•Product owner presents the set of features to the team •Team asks questions to understand the requirements in sufficient detail to enable them to commit to delivering the feature during the sprint •ScrumMaster must ensure that any other stakeholder needed to help the team understand the requirements is present or on call •At the end of SP1 the team commits to the Product Owner what they believe they can deliver in the form of running tested features

Project Selection

•Project portfolio management -A process that optimizes project selection and sequencing in order to best support business goals -Business goals are expressed in terms of •Quantitative economic measures •Business strategy goals •IT strategy goals •Once selected, projects enter the project management process

Elements of a System Request

•Project sponsor -Primary point of contact for the project •Business need -Reason prompting the project •Business requirements -Business capabilities the system will need to have •Business value -Benefits the organization can expect from the project •Special issues Anything else that should be considered

Project Team Skills

•Project team members are change agents who find ways to improve their organization •A broad range of skills is required, including -Technical -Business -Analytical -Interpersonal -Management ethical

Project Identification and Initiation

•Projects are driven by business needs -Identified by business people -Identified by IT people -(better yet) identified jointly by business and IT •The project sponsor believes in the system and wants to see it succeed -Normally this is a business person -Should have the authority to move it forward

Unified Modeling Language

•Provides a common vocabulary of object-oriented terms and diagramming techniques rich enough to model any systems development project from analysis through implementation •Version 2.0 has 14 diagrams in 2major groups: -Structure diagrams Behavior diagrams

UML Structure Diagrams

•Represent the data and static relationships in an information system -Class* (we will learn in the CIS curriculum) -Object -Package -Deployment -Component Composite structure

Sprint Backlog

•Sprint task board (what is done during this sprint)

Categories of Methodologies

•Structured Design = formal step by step approach that moves logically from one phase to the next -Waterfall Development -Parallel Development •Rapid Application Development = attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of the system developed quickly and into the hands of users. users can better understand the system and suggest revisions. -Phased -Prototyping -Throwaway Prototyping •Agile Development = all of these methodologies are bassed on agile manifesto and a set of 12 principles. emphasis of manifesto is to focus the developers on the working conditions of the developers, software, customers, processes, requirements, etc. -eXtreme Programming (XP) -Scrum

Business Value

•Tangible Value -Can be quantified and measured easily -Example: 2 percent reduction in operating costs •Intangible Value -Results from an intuitive belief that the system provides important, but hard-to-measure, benefits to the organization Example: improved customer service

Sprint Planning - Part 2 (Design)

•Team collaborates to create a high-level design of the features it has committed to deliver •Outcome of SP2 is the sprint "backlog" or the list of tasks that the team collectively needs to execute in order to turn the items in the into running tested features •During SP2 the team may ask additional questions regarding the requirements •Design is emergent and the meeting is time-boxed. Normal not to get the design perfectly done in this session and Team will discover more tasks during the sprint

The SDLC and Requirements

•The SDLC transforms the existing (as is) system into the proposed (to be) system •Requirements determination step is the single most critical step of the entire SDLC -Studies show that more than half of all system failures are due to problems with requirements

The Essence of Scrum

•The team is given clear goals •The team organizes itself around the work •The team regularly delivers the most valuable features •The team receives feedback from people outside it •The team reflects on its way of working in order to improve •The entire organization has visibility into the team's progress •The team and management honestly communicate about progress and risks

Daily Scrum Meeting (15 minutes)

•The team meets daily to communicate and synchronize its work •Essential to ensuring continued progress and avoiding work blockages •Team continuously assess its own progress towards achieving its sprint goal •Directed solely at helping the team as a whole deliver the next item in the backlog •Impediments to completing the backlog are quickly bulldozed •The ScrumMaster ensures the meeting is restricted to 15 minutes

Identifying Tasks

•Top-down approach -Identify highest level tasks -Break them into increasingly smaller units •Methodology -Using standard list of tasks

Motivation

•Use monetary rewards cautiously •Use intrinsic rewards -Recognition -Achievement -The work itself -Responsibility -Advancement -Chance to learn new skills

Product Owner Responsibilities

•Working on a shared vision •Gathering requirements •Managing and prioritizing the Product Backlog •Accepting the software at the end of each iteration •Managing the release plan The profitability of the project (ROI)

Methodology

•methodology is a formalized approach to implementing the SDLC •Well-known methodologies include: -Waterfall development -Parallel development -Rapid application development -Agile development