This document discusses methodology selection strategy for systems analysis and design. It explains that there is no single framework appropriate for every software project, and the methodology needs to be adapted to the specific team and product. It outlines important factors to consider like clarity of requirements, technology familiarity, system complexity, schedule constraints. The methodology should guide the team's process but allow flexibility. The success of the methodology is measured by timely delivery of quality product increments that satisfy stakeholders.

1. Systems Analysis
and Design
By : Ajeng Savitri P, M.Kom
Pertemuan 8
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley

2. • Learning Systems Development Life Cycle (Methodology
Selection Strategy)

3. Methodology Selection
Strategy

4. Introduction
• Every project is different, and every team is different.
• There is no single software engineering framework that is
appropriate for every software product.

5. What is it?
• Every software product needs a “road map” or “generic software
process” of some kind.
• It doesn’t have to be complete before you start, but you need to
know where you’re headed before you begin.
• Any road map or generic process should be based on best industry
practices.

6. Who does it?
• Software engineers and their product stakeholders collaborate to
adapt a generic software process model to meet the needs of team
and then either follow it directly, or more likely, adapt as needed.
• Every software team should be disciplined but flexible and self-
empowered when needed.

7. Why is it important?
• Software development can easily become chaotic without the
control and organization offered by a defined process.
• A modern software engineering approach must be “agile” and
embrace changes that are needed to satisfy the stakeholders’
requirements.
• It is important not to be too focused on documents and rituals.
• The process should only include those activities, controls, and
work products that are appropriate for the project team and the
product that is to be produced.

8. What are the steps?
• Even if a generic process must be adapted to meet the needs of the
specific products being built, you need to be sure that all
stakeholders have a role to play in defining, building, and testing
the evolving software.
• There is likely to be substantial overlap among the basic
framework activities (communication, planning, modeling,
construction, and deployment).
• Design a little, build a little, test a little, repeat is a better approach
than creating rigid project plans and documents for most software
projects.

9. What is the work product?
• From the point of view of a software team, the work products are
working program increments, useful documents, and data that are
produced by the process activities

10. How do I ensure that I’ve done it right?
• The timeliness, levels of stakeholder satisfaction, overall quality,
and long-term viability of the product increments built are the
best indicators that your process is working.

11. Selection Factors
1. Clarity of User Requirements
2. Familiarity with Technology
3. System Complexity
4. System Reliability
5. Short Time Schedules
6. Schedule Visibility
11

12. Selection Factors
12

13. Terima Kasih
ajeng.savitri@tekokrat.ac.id
https://teknokrat.ac.id/en/