Please enable JavaScript.
Coggle requires JavaScript to display documents.
SAD (Systems Development Life Cycle (Determining Human Information…
SAD
Systems Development Life Cycle
identifying problems and opportunities
Determining Human Information requirements
What are the users?
Analyzing System Needs
DFD
Designing the recommended system
Develop and Documenting System
Testing and Maintaining the System
Implementing and Evaluating the system
System Development Methods
Agile
Systems Development Life Cycle
Object-oriented Methodologies
Systems Analysis
and Design
The Context for Analysis and Design
Business Analysis
UsIng IT for Competitive Advantage
characteristics of good quality information
Relevant
Accurate.
Enough.
In time.
Clear
Constraints
Successful Systems
The Role of the Analyst and Designer
three other important points of Systems Analysis and Design
Systems analysis and design involves people. Certainly it involves technology, often technology that we don’t really understand and which we rely on other people to manage for us, but the best-designed systems in the world succeed because the people who use them can do their jobs better. This is because their information systems enable them to achieve goals they wouldn’t otherwise reach. There are just too many people on trains and planes using laptop machines to believe that we can ever in the future manage without computers. The importance of this ‘people aspect’ is emphasised later where we consider change management.
Systems analysts and designers change the world. This is a bold statement, and in one sense everyone changes the world to some extent just by their very existence. The role of the systems analyst, however we may describe it in detail, is to be a change agent. Unless we are interested in changing the way organisations work we have no need for systems analysts. Unless you are interested in changing the way organisations work, you probably have no need to read this book.
Information systems are expensive to develop and maintain, so it is clear that businesses do not commission them just for the fun of it. The need for an information system must grow out of some perceived business requirement, and the justification for it must be expressed in business terms. Although this is well enough understood in theory, it is surprising how often IS projects do start without clear links back to business plans and strategies. System developers often take the sketchiest of briefs and start to develop something they think meets the need – and are then unpleasantly surprised when the user or sponsor of the system refuses to accept it because it does not properly meet their specific business requirements.
Workflow
Define main task areas
Defining