Software Development Life Cycle (SDLC)
- Planning and Requirement ANalysis • Inputs from the customer, the sales department, market surveys and domain experts in the industry • Quality assurance requirements and identification of the risks • Technical feasibility study
- Defining Requirement • Define and document the product requirements • SRS (Software Requirement Specification, 소프트웨어요구명세) document which consists of all the product requirements to be designed and developed
- Designing the Product Architecture • Based on SRS, multiple designs can be proposed • Then, select one by stakeholders based on risk assessment, product robustness, design modularity, budget and time constraint • Define all the architectural modules of the product along with its communication and data flow representation with the external and third party modules
- Building or Developing the Product • Building the product (e.g., coding) • Developers must follow the coding guidelines provided by their organization or programming tools
- Testing the Product • Test only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS
- Deployment in the Market and Maintenance • Once the product is tested and ready to be deployed it is released formally in the appropriate market • The product may first be released in a limited segment and tested in the real business environment • Based on the feedback, the product may be released as it is or with suggested enhancements • Once the product is released, maintenance is done for the existing customer base
Waterfall Model
- 전체 과정이 단계들로 나뉘어져 있다.
- 계속적으로 하나 단계의 결과가 다음 단계의 input으로 작동한다.
- 장점
- 간단하고 이해하기 쉽다
- 각 단계가 특정적으로 전달이 가능하고 리뷰과정이 있다.
- 작은 프로젝트에 잘 작동한다.
- 한 번에 하나씩 처리 및 완료
- 손쉬운 작업 정리
- 단점
- last phase까지 작동하는 SW가 생성되지 않음
- 높은 위험과 불확실성
- 길고 복잡한 프로젝트에서는 적절하지 않음
- 바뀌는 요청들에 수용적이지 않음
Agile model
- 일들이 time boxes로 나뉨
- iterative model (반복모델)
- 각 build는 기능 측면에서 점진적
- 장점
- 빠르게 부분적인 working solutions을 전달한다
- 지속적으로 변하는 환경을 위한 좋은 모델
- 개발자에게 flexibility를 줌
- 기능이 빠르게 개발되고 시연할 수 있게.
- 단점
- 소비자 interaction에 너무 의존함
- not suitable for handling complex dependencies
- sustainability, maintainability and extensibility 에 더 많은 리스크가 있음
- 최소한의 문서 생성
- Agile Model Method: Scrum
- a framework that helps teams work together
- sprint : a short, time-boxed period
- sprint planning
- backlong
- standup meeting
- roles : product Owner, scrum master, devloper
Prototyping
- 디자인 과정 전에, 소비자에 의한 개발, 테스트, 리뷰, 승인되는 것
- 디자인이 코딩 준비가 된 후 테스트, 설치 및 유지 관리가 수행됩니다.
프로토타이핑 특징 장점 단점
| 아날로그 | 연필, 종이 | 빠르고 간단 | 구체적이지 않음, 구현할 항목이 많은 경우 오래걸림 |
| 디지털 - low fidelity | 보여주기 혹은 인터랙션 가능 | 하나 혹은 다수의 프로세스 표시 가능, 수정이 비교적 간단 | 시스템의 특징을 살리기 어려울 수 있음 |
| 디지털 - high fidelity | 인터렉션과 장식적 요소까지 구현 | 가장 구체적, 이해가 빠름, 특징을 모두 구현 가능 | 제작이 오래 걸림, 수정이 힘 |
사용자 경험 디자인 (UX) : 사용자가 어떤 제품, 시스템, 서비스 등을 직접적 혹은 간접적으로 이용하면서 느끼는 반응과 행동들과 같은 경험을 총체적으로 설계하는 것 (내용, 구성)
사용자 인터페이스 디자인 (UI) : 사용자가 제품을 어떤 방식으로 이용하게 만드는 지를 디자인 (레이아웃, 구조, 색상, 모양)
How to design good prototype
- participatory design : 사용자를 참여시켜라
- User Flows and Scenarios :
- 첫째, 페이지 플로우를 디자인하자 즉 사용자가 사이트를 최적으로 이용할 수 있는 플로우를 그려봄
- 둘째, low-fidelity prototyping후, 그린 각 페이지당 3-5개의 variation들을 만들어보고 usability test
- 사용자의 플로우와 기능들이 픽스되었다면 fidelity를 증가해 좀 더 실감나는 프로토타이핑
- 사용자 인터랙션은 simple할수록 좋다
- fewer clicks mean less friction, which means better user flow
- 하지만 사용자의 상호작용을 침해해서는 안됨
- three clicks rule을 어겨도 괜찮음
- 애니메이션을 적절히 활용
- 실감나는 프로토타입을 만들 수 있음
- 사용자 테스트에 도움이 됨
- 효과적인 UI 디자인을 위한 전략
- Design finger-friendly tap-targets : 타겟크기 최소 10mm, 서로 너무 가깝지 않게 배치
- 적절한 폰트크기
- 필요한 데이터만 입력받게 함
728x90
