1. Prince Sultan College for Women
Course Code : IS 225
Course Name : Systems Analysis & Design- I
Course Instructor : Omarine Rafie
Credit Hours : 4
Text Book : Systems Analysis & Design
Author(s) : Jeffery Hoffer, Joseph Valich 5th Edition
Reference Book :
1. Systems Analysis & Design By Jeffery Whitten

2. Chapter 1 The Systems Development Environment
1.1

3. Learning Objectives Define information systems analysis and design
Describe three types of information systems:
Transaction Processing Systems (TPS)
Management Information Systems (MIS)
Decision Support Systems (DSS)
1.2

4. Learning Objectives
Describe the information systems development life cycle (SDLC)
Water fall Model
Discuss Rapid Application Development (RAD) and its constituents parts
Prototyping
JAD
CASE
1.3

5. Learning Objectives
Describe Object Oriented Analysis and Rational Unified Process (RUP)
Describe the Agile Methodologies and eXtreme Programming
1.4

6. Information System-Introduction
An Information system ( IS) is a collection of interrelated components (hardware, software, and telecommunications networks) that people build and use to collect, process, store and provide/distribute as output useful information needed to complete a business task in organizations.
Examples:
Payroll System
Sales Management System

7. Information System-Introduction
Why do we design Information Systems?
Information systems are built and rebuilt
To provide access to information anywhere and anytime.
for organizational benefits by adding values during the process of creating, producing and supporting the organization’s product and services.
to improve employee efficiency by applying software solutions to key business tasks
Understand what the business requires from the Information System. In other words thorough “Systems Analysis & Design”

8. What is Systems Analysis & Design?
Systems Analysis means understanding and specifying in detail what the information system should accomplish.
Systems Design means how to accomplish what is needed by the information system, by specifying in details how many components of the information system should be physically implemented.

9. What is Systems Analysis & Design?
Information Systems Analysis and Design
Complex, challenging and stimulating organizational process used by a team of business and system professionals, to develop and maintain computer-based information systems that helps in performing business functions efficiently.
1.5

10. What is the outcome of SAD ?
The total Information System includes the hardware, systems software on which the application software runs, documentation and training materials, the specific job roles associated with the overall system and the end users.
An important result of Systems A&D is Application Software, i.e. software designed to support a specific organizational function or process, such as Inventory management, payroll etc.

11. Who is Systems Analyst?
Systems Analyst performs analysis and design based upon:
Understanding of organization’s objectives, structure and processes.
Studies the problems and needs of an organization
Knowledge of how to exploit information technology for advantage
Determine how people, methods and IT can be best combined to bring about improvements in the organization.
1.8

12. Types of Information Systems
Transaction Processing Systems
Management Information Systems
Decision Support Systems
1.12

13. Types of Information Systems
Transaction Processing Systems (OLTPS)
Automate handling of data about business activities (transactions- discrete events)
the routine day to day business processes
Data about each transaction are captured, transaction are verified and accepted or rejected, and validated transaction are stored for later aggregation.
A transaction occurs each time a sale is made, supplies are ordered or interest payment is made
1.13

14. Types of Information Systems
Transaction Processing Systems (TPS) -contd.
The A&D of a TPS means
Focusing on the firm’s current procedures
The goal of TPS development is to
improve transaction processing by speeding it up using fewer people,
improve efficiency and accuracy,
integrate it with other organizational information systems,
provide information not previously available.
1.14

15. Types of Information Systems
Examples of TPS
Business to consumer e commerce systems
Point of Sale System
Online Registration System
Online Airline Reservation System
ATM System
Car Rental System
Library Information System
Business to Business e commerce systems

16. Types of Information Systems
Management Information Systems (MIS)
Converts raw data available through a transaction processing system into meaningful aggregated form (report) that managers need for planning and controlling business.
Examples of MIS
MIS used by executives often include external data on the competitive environment –
news about competitors
Stock market reports
Economic forecast
Information from strategic plans.

17. Types of Information Systems
Decision Support Systems (DSS)
Designed to help organizational decision makers make decisions.
Allows a user to explore the impact of available options or decisions, and this is known as “what if” analysis, because the user asks the system to answer.
Provides interactive surroundings for decision making in which data can be quickly manipulated.
DSS uses both historical data as well as judgment about alternative histories or possible futures.
A DSS can help in exploring data at a high level of aggregation and selectively drill down into specific areas where more detailed understanding of business is required.

18. Types of Information Systems
The A&D for a DSS concentrates on
Database (data Orientation)
Model base ( mathematical rules defining interrelationships among different data, used to predict future data or to find best solutions to decisions problems.
User dialogue – decision maker should feel easy to use the system.
The A&D for a DSS is to document the mathematical rules with the intention of define the relationships among different data or to find the best solutions to decision problems.

19. Approaches to Systems Development
Two approaches to system development
Traditional approach
Object oriented approach

20. The Traditional Approach
Also called Structured System Development
Three techniques are used
Structured Analysis- What the system needs to do (process requirements), what data the system needs to store (data requirements), what inputs and outputs are needed, and how the functions work together as a whole to accomplish tasks before they designed the programs.

21. The Traditional Approach
Structured Design –As each function performed by the system might be made up of dozens of separate programs, it provides guidelines of deciding what the set of programs should be, what each program should accomplish and how the programs should be organized into a hierarchy.
Structured programming- complex programs are divided into a hierarchy of program modules. One module at the top of the hierarchy controls program execution by calling lower modules as required.

22. Object Oriented Approach
It views an information system as a collection of interacting objects that work together to accomplish tasks.
Object Oriented Analysis (OOA) defines all of the types of objects that do the work in the system and shows what user interactions called use cases are required to complete tasks.
Object oriented design (OOD) defines all of the additional types of objects necessary to communicate with people and devices in the system, shows how the objects interact to complete tasks and refines the definition of each type of object so it can be implemented with a specific language or environment.
Object Oriented Programming (OOP) consists of writing statements in a programming language to define what each type of object does.

23. Systems Development Life Cycle
System Development methodology-
Standard set of steps to develop and support IS.
Development of IS follows a life cycle. During the life of an IS, it is first conceived as an idea, then it is designed, built and deployed during a development project and finally it is put into production and used to support the business.
SDLC – common methodology for system development
SDLC is used to describe the life of an information system from conception to retirement.

24. Systems Development Life Cycle
Life Cycle – a circular process
Life cycle appear to be sequentially ordered set of phases, but it is not.
Some activities in one phase can be completed in parallel with some activities of another phase.
Sometimes life cycle is iterative- phases are repeated until accepted.

25. Systems Development Life Cycle
Series of steps used to manage the phases of development for an information system
Consists of five phases:
Planning
Analysis
Design
Implementation
Maintenance
Each phase has a specific outcome and deliverable
1.25

26. Systems Development Life Cycle
Planning
Ch 16
Ch 4-5
Maintenance
Analysis
Ch 6-9
Implementation
Design
Ch 15
Ch 10-14

27. Systems Development Life Cycle
Planning- Ist Phase
Project Identification and Selection
Project Initiation and Planning

28. Systems Development Life Cycle
Project Identification and Selection
Examine Information needs.
Identify the project
Prioritization and translation of needs
Development of Schedule for different projects
Selection of a project.
Project Initiation and Planning
Two Activities
Formal preliminary investigation of the problem at hand
Determining the scope of the proposed system known as Feasibility Study
Producing a specific plan (Baseline project plan) for the proposed system if it has been approved, specifying the time and resources needed for its execution.
Outcome
Final presentation of the business case
1.28

29. Systems Development Life Cycle
Analysis - 2nd Phase
To understand and document the business needs and the processing requirements of the new system.
A discovery and understanding process.
Activities
Gather information
Define system requirements
Build prototypes for discovery of requirements
Prioritize requirements
Generate and evaluate alternatives matching the requirements
Review recommendations with management.
Outcome
Once the recommendation is accepted, the analyst makes plans to acquire hardware and software necessary to build or operate the system as proposed
1.29

30. Systems Development Life Cycle
Design- 3rd phase
Used to design the solution system, based on the requirements defined and decisions made during analysis.
High level design consisting of developing an architectural structure for the software components, database design, user interfaces and operating environment.
Low level design entails developing the detailed algorithms and data structures required for software development.
1.30

31. Systems Development Life Cycle
The description of recommended alternative solution is converted into
Logical design Physical design
Logical design focuses on “what” rather than the “how”.
Logical design process is independent of any specific hardware or software platform – logical design.
Logical design concentrates on the business aspects of the system.
Logical design is oriented towards high level of design

32. Systems Development Life Cycle
Physical design concentrates on the design of the various parts of the system to perform the physical operations necessary to facilitate data capture, processing and information output. Physical design includes -Hardware selection, determination of software ( custom/off- the-shelf applications) -Design of user interface -Data capture devices -Data input and report formats -The media to be used for input and output -Construction of database structure -Network communication, data security etc Outcome: Physical system specifications in a form ready to be turned over to the programmers or other system builders for construction e.g. programming language, database, hardware platform

33. Systems Development Life Cycle
Implementation-4th phase
Implementation
Coding- programmer write the program for the system
Testing
Operation
Hardware and software installation
User Training
Documentation

34. Systems Development Life Cycle
Coding
Programs can be written in Java, Visual Basic etc.
Testing
Individual testing of the programs
System or Integration testing

35. Systems Development Life Cycle
Operation (System conversion) :
It is the process abandoning the current system (automated or manual) and installing the new automated information system.
System conversion can be done in at least three ways : 1. Direct changeover : Old system is discontinued on one day and the new is used on the next. 2. Parallel running : Old and new systems are used at same time. 3. Phased changeover : Part of the new system are implemented in phases.

36. Systems Development Life Cycle
Installation
Application software is installed on existing or new hardware.
The new system becomes a part of the daily activities of the organization.
Training
Users are trained.
Occurs from inception of a project.

37. Systems Development Life Cycle
Documentation :
Many types of documentation must be produced for a software system
System documentation : Software Engineers develop system documentation that details the inner working of the system to ease future maintenance.

38. Systems Development Life Cycle
User Documentation : It is user–related documentation which contains the following User and reference guides, User training and tutorials Installation procedures and troubleshooting suggestions. Initial user support
In addition to documentation, users may also need training program and on going support to use a new system.

39. Systems Development Life Cycle
Maintenance- 5th Phase
Maintenance means system is changed to reflect changing conditions
Corrective Maintenance : Making changes to an information system to repair flaws in the design, coding or implementation.
Adaptive Maintenance : Making changes to an information system to accommodate changing business needs .

40. Systems Development Life Cycle
Perfective Maintenance : Making enhancements to improve processing performance or interface usability.
Preventive Maintenance: Making changes to a system to reduce the chance of future system failure.

41. Methodologies, Models, Tools And Techniques
Systems Analyst have a variety of aids at their disposal to help them complete activities and tasks in the SDLC.
Methodology
Models
Tools
Techniques

42. Methodologies, Models, Tools And Techniques
Systems Analyst have a variety of aids at their disposal to help them complete activities and tasks in the SDLC.
Methodology : provides guidelines that are used to complete activities within each phase of the SDLC. Or instructions about how to use models, tools and techniques in every phase.
Models: is a graphical representation of an important aspect of the real world. Models represents inputs, outputs, processes, data objects, object interactions, locations, networks, devices etc.
Tools: Software support that helps create models or other components required in the project
Techniques: is a collection of guidelines that help an analyst complete a system development activity or task.

43. Methodologies, Models, Tools And Techniques
Flow Chart
Data Flow Diagrams
Entity-Relationship Diagram
Structure Chart
Use Case Diagram
Class Diagram
Sequence Diagrams etc.

44. Methodologies, Models, Tools And Techniques
Word processor
Database management application
Project management application
Computer Aided System Engineering tools etc.

45. Methodologies, Models, Tools And Techniques
User interviewing techniques
Joint Application Development (JAD)
Data modeling technique
Strategic planning technique
Structure design technique
Software testing technique

46. Approach to Systems Development
Process-Oriented Approach
Earlier information system’s design was based upon what the system was supposed to do, such as billing and inventory control: the focus was on input, output and processing logic.
Data was considered as subordinate to the application, as it had to match the specification in each application. And each applications was considered separately.
1.46

47. Approach to Systems Development
Process-Oriented Approach ( contd.)
Involves creating graphical representations such as data flow diagrams and charts
Data are tracked from sources, through intermediate steps and to final destinations
Natural structure of data is not specified
Disadvantage: data files are tied to specific applications. Duplication of data in every application. Mismatching of data in different applications.

49. Approach to Systems Development
Data-Oriented Approach
Depicts ideal organization of data, independent of where and how data are used
Data model describes kinds of data and business relationships among the data
Business rules depict how organization captures and processes the data
1.49

50. Approach to Systems Development

51. The Traditional Waterfall SDLC
This model is known as ‘water fall model’ because, the output of one phase is the input of the next phase.
It is a traditional methodology used to analyze, design, implement and maintain information system.
The flow of the project begins in the planning phase, just like a stream that runs off a cliff.

52. The Traditional Waterfall SDLC
Planning
Analysis
Design
Implementation
Maintenance

53. The Traditional Waterfall SDLC
Strengths:
The water fall cycle is a very good approach to follow when the requirements for the information system are highly structured and straightforward and at the same time they are known in the early phases only. e.g. payroll, or inventory system.
Tackles complexity in an orderly way, works well for well understood projects That is why, waterfall model is mostly used for large systems engineering projects.

54. The Traditional Waterfall SDLC
Drawbacks
This model requires that all the requirements should be specified in advance. It is difficult for end-users to anticipate how they will use new information systems to support their everyday work. If these systems are large and complex, it is probably impossible to make this assessment before the system is built and put into use. In short, the requirements are not clear to the end-users in the beginning.

55. The Traditional Waterfall SDLC
Drawbacks
It was not possible to implement changes in the requirement specifications all the time during system development. The analyst freeze requirements in the early phase, even though those requirements might get changed. With the result it is very expensive to make changes in a system once it was developed.
The role of users are narrowly defined. Limited User involvement throughout the system development.

56. The Traditional Waterfall SDLC
Drawbacks contd.
Focus on milestone deadlines, instead of obtaining feedback from the development process leads to too little focus on good analysis and design.
Focus on deadlines results in systems that do not match users’ needs and that require extensive maintenance, unnecessarily increasing development cost (maintenance cost is 40% – 70% of software development costs). Finding and fixing a problem after implementation is 100 time more expensive than finding and fixing it during A&D.

57. Different Approaches to improving Development
Prototyping
Joint Application Design
Case tools
Time Boxed Approach

58. The Prototype- Approaches to Improve Development
What is a Prototype ?
An easily modifiable and extensible working model of a proposed system, not necessarily representative of a complete system
What is a Prototyping ?
Prototyping is the process of building a working replica of a system.
A prototype can be developed with visual development tool with the query, screen and report design tools of a database management system and with CASE tools.

59. The Prototype- Approaches to Improve Development
The Prototype Software Development approach is used to counter the limitations of the waterfall model. The basic idea is that instead of freezing the requirements before any design or coding can process, a prototype is built to help understand the requirements by exposing it to the user comment and refining this through many versions until adequate system has been developed.
Development of the prototype undergoes design, coding and testing, but each of these phases is not done formally or thoroughly. Rather these activities are carried out concurrently with rapid feedback across these activities.

60. The Prototype- Approaches to Improve Development
By using this prototype , the client can get an actual feel of the system, because the interactions with the prototype can enable the client to better understand the requirements of the desired system. The prototype can be refined through many versions until adequate system has been developed.
This results in more stable requirements that change less frequently.

61. The Prototype- Approaches to Improve Development
Strengths:
The end user can see the system requirements as they are being gathered by the project team-customers get early interaction with system.
There is less room for confusion, miscommunication or misunderstanding in the definition of the system requirements, leading to a more accurate end product.
The model allows flexible design and development, including multiple iterations through life cycle phases. With the result new or unexpected user requirements can be accommodated.

62. The Prototype- Approaches to Improve Development
Strengths:
In addition to being used as a stand alone process, prototyping may also be used to augment the SDLC. e.g. a prototype of the final system may be developed early in analysis to help analyst identify what users want. The final system is developed based on the specification of the prototype.

63. The Prototype- Approaches to Improve Development
Drawbacks:
Prototypes evolve so quickly that it is not cost-effective to produce a great deal of system documentation. Further more rapid prototype development may require unfamiliar technologies to be used. Managers find it difficult to use existing staff because they lack these skills. Sometimes quick and dirty prototypes are developed which suffers from inadequate or missing documentation.

64. The Prototype- Approaches to Improve Development
Drawbacks
Continual change tends to corrupt the structure of the prototype system. This means that anyone apart from the original developers is likely to find it difficult to understand. Therefore finding people who have the required knowledge to maintain the system may be difficult.
In the rush to create a working prototype, overall software quality or long term maintainability may be overlooked.

65. JAD - Approaches to Improve Development
Joint Application Design (JAD)
A new process for collecting information system requirements and reviewing systems design.
To bring structure to the requirement determination phase
Users, Managers and Analysts work together for series of intensive and structured meeting run by a JAD session leader.
Structured meetings and adherence to the agenda.
Advantages
Time and organizational resources are better organized, by working together in one room.
Stakeholders develop a shared understanding of what the information system is supposed to do.
1.65

66. CASE (Computer-Aided Software Engineering) - Approaches to Improve Development
Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support
Diagramming tools- graphical representation
Computer display and report generators- look and feel
Analysis tools-check for incompleteness, inconsistency or incorrect specification in diagrams, forms, reports .

67. CASE (Computer-Aided Software Engineering) - Approaches to Improve Development
Central Repository- integrated storage of specifications, diagrams, reports, project management information
Documentation Generators- technical and user documentation
Code generators- enable the automatic generation of program and database definition code directly from the design documents, diagrams, forms and reports

68. CASE Tools
Microsoft Visio
Visible Analyst
Rational Rose
Oracle

69. Time-boxed approach - Approaches to Improve Development
It is a method applied during the analysis or construction phase to control the scope of a project by imposing an immovable deadline on the completion of a task, activity, stage or system by strictly controlling functionality.
RAD allows development teams to quickly build the core of the system and implement refinements in subsequent releases.

70. Rapid Application Development
RAD is a methodology that ensures organizations the ability to develop and deploy strategically important systems more quickly while simultaneously maintaining quality and reducing development cost.
The approach provides a series of techniques for compressing the analysis, design, build and test phases into a series of short iterative development cycles.

71. Rapid Application Development
System developers and end-users work together jointly in real time to develop system
Use of small, well trained development teams
Phases are shortened and combined with each other.
System is developed in isolation from other systems.
Tasks done in parallel rather than sequentially.
Prototyping is used extensively.

72. Rapid Application Development
Construction and review of iterative , evolutionary prototypes
Reliance of integrated development tools that support modeling, prototyping and component reusability (CASE). Examples: VisualAge Generator, VisualAge for Java, WebSphere Studio, WebSphere Application Server. They enable fast, easy development of e-business applications.
Heavy reliance on JAD and design workshops
Adoption of a time-boxed approach to development. i.e. adherence to limits on development time frames.

73. Rapid Application Development
Requirement
Planning
User Design
Construction
Cutover

74. Rapid Application Development
Advantages:
Active user involvement throughout RAD life cycles, which ensures that business requirements and user expectations are clearly understood by all participants.
RAD takes full advantage of powerful application development tools, such as CASE, to rapidly develop high quality applications.

75. Rapid Application Development
Major use of iterative prototyping is employed to help users visualize and request changes to the system as it is being built, allowing applications to evolve rapidly.
RAD techniques are considered desirable in environments with unstable business requirements or requiring the development of unique, non traditional applications.

76. RAD – Comparing RAD to the SDLC
Labor – intensive activities of the SDLC are condensed through parallel actions
Use of JAD requirement
Extensive iterative process.
Includes the development and refinement of process models and prototype
In waterfall model, activities are performed in a sequential manner whereas in RAD approach they are performed in a iterative, parallel manner.
In RAD, user requirements are refined, a solution is designed, the solution is prototyped, the prototype is reviewed, user input is provided and the process begins again.

77. Consider RAD
The software application will run stand alone without other system interactions
Application performance is not mission critical
Application distribution will be narrow
Project scope is significantly constrained
The required technology is considered mature.

78. Avoid RAD when
Applications must interact with existing system applications
Optimal performance is mission critical
Application development cannot take advantage of high end IS tools.
Application distribution will be wide.
Project involves building operating systems or computer games etc.
Technical feasibility is low due to use of new technology

79. Object Oriented Analysis and Design
Data and process are combined in to single entity known as objects.
Objects correspond to the real things an information system deals with, such as customer, supplier, contracts, rental agreement etc.
Maintenance of the software becomes much easier
Inheritance property makes the system elements more reusable, thus improving the quality and the productivity of systems analysis and design.

80. Rational Unified Process ( RUP)
Based on an iterative, incremental approach to system development.
Phases
Inception,
elaboration,
construction,
transition

81. Rational Unified Process ( RUP)
Inception
Define the scope
Determine the feasibility of the project
Understand the user requirements
Prepare software development plan
Short phase and the least resource intensive.
Single iteration

82. Rational Unified Process ( RUP)
Elaboration
Major activities –Detailed Analysis (Define the requirements), design the solution and implement the solution.
Long phase and has several iterations
Most critical phase
Create use case diagrams, class diagrams, sequence diagrams etc.
Final cost and benefits estimates are also completed.
The architecture includes a vision of the product, an executable demonstration of the critical pieces, a detailed glossary and a preliminary user manual, a detailed construction plan and a revised of planned expenditures.

83. Rational Unified Process ( RUP)
Construction
Continue to build the system with additional features using number of iterations that also include requirements, design and implementation, possibly creating multiple releases of the system.
Longest phase
Several iterations
Revised user requirements could require analysis and design.
The components are developed, purchased and used in the code.
At the end beta version of the project is released that should have operational capabilities.

84. Rational Unified Process ( RUP)
Transition
The project gets acceptance in this phase
The System is deployed, and the users are trained and supported.
Resource intensive but short phase.

85. Rational Unified Process ( RUP)
Each phase is divided in iterations.
Software is developed incrementally as a series of iterations.
Inception – 1 iterations
Elaboration – 1- 2 iterations or max. of 4
Construction – several iterations

86. Agile Methodologies
Software development Methodology adapted from engineering generally do not fit with the real world software development.
For engineering disciplines such as civil, requirements tend to be well understood. Once designing is completed, constructions becomes very predictable.
For software engineering, requirements are rarely well understood; they change continually during the lifetime of the project.

87. Agile Methodologies What is needed in software engineering?
It should embrace change
It should be able to deal with a lack of predictability.
Agile methodologies is based on the above principles, which focuses on
Iterative development
Focus on people
Promotes self adaptive software development process

88. Agile Methodologies Iterative development
Frequent production of the working versions of a system that have a subset of the total number of required features.
Provides feedback to the customer and developers alike.

89. Agile Methodologies Focus on people
Focus on individuals rather than on the roles those people perform.
Roles are not as important as the individuals who fill those roles
Doesn’t view people as interchangeable units instead as talented individuals.

90. Agile Methodologies
Promotes self adaptive software development process
The process used to develop software should be refined and improved by reviewing it repetitively which is of course done by a number of iterations.
AS the processes are adapted (modified), one would not expect to find a single monolithic methodology within an organization, instead many variations of the methodology which reflects the particular talents and experience of the team using it.

91. Agile Methodologies When should we recommend Agile methodologies?
Unpredictable or dynamic requirements
Responsible and motivated developers
Customers who understand the process and will get involved

92. Class Discussion on Extreme programming and Scrum
Agile methodologies
In situations having uncertainties in requirements, resources, time and risks.
Requires responsible and motivated team
Requires processes meeting your unique needs.
Requires good management and reporting techniques to control the project.
Focus on adapting quickly to changing realities.
Face to Face communication.
Working software as the primary measure of progress.
Increments delivered in weeks.
Time period as a strict time-box ( 1- 4 weeks)
Provides feedback to customers and developers.
Frequent production of working versions of a system.

93. Extreme Programming
Follows a set of design principles ( Communication, feedback, Simplicity, Courage and Respect
Focus on software
Short cycles
Incremental planning approach
Focus on automated test written by programmers/customers
Evolutionary approach to development
Two-person programming teams
Customer on site during the development process.
Building working system in a very little time, without written or diagramming design specification.
Simple designs and use re-factoring technique which makes a program simpler after adding a new feature.

94. Extreme Programming
When people work in a group, the lose a feeling pf individual responsibility.
Long term commitment and dedication is required from both the user and customer.
Lack of design documentation.
Pair programming not cost effective
Not effective on large projects
Requires experienced developers
Neglected planning

95. Scrum Focus on improving productivity in teams ( 4 x)
Iterative , incremental process for developing product.
Focus on management techniques
Customer see on-time delivery of increments.
Creates an environment of success.
Progress is made even when requirements are not stable.
Everything is visible to everyone.
Team communication improves.

96. Scrum Development in 30 day sprint cycles
Sprint : a period of 30 days or less where a set of work is to be achieved, led by Scrum Master( his job is to remove obstacles faced by the team)
Backlog : All work to be performed in the near future.
Sprint backlog: the work to be done during the current sprint
Product backlog : the work that should be done for the whole product as desired by the customer.
Scrum : A daily meeting at which progress and obstacles are reviewed every day. ( 15 minutes)

97. Scrum
Management must be willing to make changes to help scrum team succeed.
Manager must let scrum team make their own decisions, even allowing them to fail if necessary.
People are resistant to change the methodology
Some workers are not comfortable with the responsibility Scrum enforces.