0% found this document useful (0 votes)
24 views26 pages

SE Chapter5 Models Architecture Choosing

Uploaded by

huy.pmg16
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views26 pages

SE Chapter5 Models Architecture Choosing

Uploaded by

huy.pmg16
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

SOFTWARE ENGINEERING

CHAPTER 5.
ANALYSIS AND SELECTING
SOFTWARE DEVELOPMENT MODEL
AND ARCHITECTURE

Dr. NGUYỄN QUANG VŨ


E-mail: [email protected]
Handphone: 0901.982.982
CONTENTS

 Analysis and selecting software development


model;

 Analysis and selecting software architecture;

 Case study;

 REFERRENCES
 Fundamentals of Software Architecture: An
Engineering Approach, Mark Richards, Neal Ford,
2020.
 Software Engineering (10th Edition), Ian
Sommerville, 2016.
1. Analysis and selecting software development model
 Overview
 There is no one-size-fits-all software development model;

 Each model has its own advantages as well as disadvantages for different software projects
and development teams.

 It can be selected by keeping the advantages and disadvantages of various models in mind.

 The choice of software development model depends on the following basic factors:

- Characteristics of the software to be developed;


- Characteristics (knowledge, experience,…) of the development team;

- Risk associated with the project;

- Characteristics of the customer.


1. Analysis and selecting software development model
 Criteria that should be set when analyzing and choosing a software
development model:
(1) Does the customer understand all the requirements (their expectations) of the
software?

(2) How can customers be involved in the software development process?

(3) Are the software requirements clear and stable?

(4) Size, skills, software engineering capabilities and suitability of the development
team for the software project?

(5) Which model is suitable for the technology chosen to implement the solution?
1. Analysis and selecting software development model
 Criteria that should be set when analyzing and choosing a software
development model (cont’d):
(6) What are the customer and stakeholder concerns and priorities?

(7) What is the type, size and complexity of the software?

(8) What are the quality requirements of the software?

(9) Have the risks in the development process been identified, analyzed and proposed
solutions to prevent?

(10) What is the cost and time spent on the software project?
1. Analysis and selecting software development model
 The factors contribute to choosing the Waterfall model
 Short-term projects.
 Clear, fixed, and well-documented requirements.
 Static technology that is understood.
 Stable product definition.
 A variety of resources for product support.
 Low Product Owner Involvement.
 Strictly-set timeline.
 Fixed budget that cannot be changed.
1. Analysis and selecting software development model
 The factors contribute to choosing the V-Shaped model

 The project is short-term and not complex.

 Clearly defined, documented, and stable requirements.

 The technology used is also stable.

 The project team has a full understanding of the project and the technology.
1. Analysis and selecting software development model
 The factors contribute to choosing the Iterative model

 System requirements are clearly defined and fully understood by all of


stakeholders.

 Additional requirements can occur with time.

 When the team learns new technology and works on the project simultaneously.

 Specific resources are to be used only when they are required for specific iterations
according to the contract.

 When the business goals might change in the future due to high-risk features.
1. Analysis and selecting software development model
 The factors contribute to choosing the Spiral model
 There’s a budget limit and you need to foresee risks.
 You have a medium or high-risk project to carry out.
 There is a long-term project, and changes might occur.
 The requirements are vague to the customer and need more clarity due to
their complexity
 The primary product has to be released in several stages to get valuable
customer feedback.
 You expect major changes to the product during the SDLC.
1. Analysis and selecting software development model
 The factors contribute to choosing the Prototype model

 Prototyping is applicable to online software system development where there


is a high level of user interaction:
 Systems that require users to fill out forms.

 Software that requires lots of data processing.


1. Analysis and selecting software development model
 The factors contribute to choosing the Agile model
 In small to medium-sized software projects (Or a large project can be divided into small
independent projects).
 To produce the required multiple variants of the product.
 When you need to break down the development process into smaller parts – iterations.
 When there’s a need for software delivery acceleration.
 When the team needs to be flexible in changing priorities.
 When the need is to enhance software quality, productivity, and predictability in delivery.
 To promote project risk reduction and achieve cost reduction possibilities.
 To manage the distributed teams effectively on the project.
1. Analysis and selecting software development model
 The factors contribute to choosing the DevOps model

 The complex projects.

 Projects that require QA and testing.

 Projects that include large teams from multiple departments.


1. Analysis and selecting software development model
 Comparison between software development models based on criteria

Evolutionary Iterative and


Factors Waterfall V-Shaped Spiral Agile
Prototyping Incremental
Unclear User Requirement Poor Poor Good Excellent Good Excellent
Unfamiliar Technology Poor Poor Excellent Excellent Good Poor
Complex System Good Good Excellent Excellent Good Poor
Reliable system Good Good Poor Excellent Good Good
Short Time Schedule Poor Poor Good Poor Excellent Excellent
Strong Project Management Excellent Excellent Excellent Excellent Excellent Excellent
Cost limitation Poor Poor Poor Poor Excellent Excellent
Visibility of Stakeholders Good Good Excellent Excellent Good Excellent
Skills limitation Good Good Poor Poor Good Poor
Documentation Excellent Excellent Good Good Excellent Poor
Component reusability Excellent Excellent Poor Poor Excellent Poor
2. Analysis and selecting software architecture
 Software Architecture Design Guidelines

 Think of what to do before thinking of how to do it.

 Think of abstract design before thinking of concrete design.

 Think of non-functional requirements earlier.

 Think of software reusability and extensibility as much as possible.

 Tolerate refinement of design.

 Promote “High cohesion” in each component and “Loose Coupling”


between components;
2. Analysis and selecting software architecture

 Architectural design space


 Design alternatives (different solutions for a problem) that can

 support functional and non-functional requirement specifications.

 Major challenge
 how to produce “agile” software architectures that

 can be easily adapted to their changing environments without major re-engineering


2. Analysis and selecting software architecture
 Architecture depends entirely on the analysis of requirements and expected quality
attributes.

 Procedure
(1) Select the architectural patterns in accordance

with functional requirements;

(2) Determine the expected quality attributes;

(3) Quantify the quality attributes;

(4) Sum (weighted) scores of quality attributes;

(5) Select the most appropriate architectural pattern(s);


2. Analysis and selecting software architecture
 Focus on quality attributes

 Quality attributes are closely related to architectural styles;

 Each architectural style supports some quality features and has its advantages,

disadvantages and potential risks;

 Choosing the right architectural style to satisfy required quality attributes is also very

important, in addition to functional requirements satisfaction..

 An architectural style encapsulates tradeoffs among many conflicting quality attributes.


2. Analysis and selecting software architecture
 Quality attributes classification

 Implementation attributes

 not observable at runtime

 Runtime attributes

 observable at runtime

 Business attributes
2. Analysis and selecting software architecture
 Quality attributes classification

 Implementation attributes
 Interoperability;
 Maintainability;
 Extensibility:
 Testability;
 Portability;
 Scalability;
 Flexibility;
2. Analysis and selecting software architecture
 Quality attributes classification

 Runtime attributes
 Availability;
 Security;
 Performance;
 Usability;

 Bussiness attributes
 Time to market;
 Cost;
 Lifetime;
Quality attributes trade-off

 Tradeoff between space and time.


 Ex: to increase the time efficiency of a hash table means to decrease its space efficiency.

 Tradeoff between reliability and performance.


 Ex: Java programs are well protected against buffer overflow due to its security measures

such as boundary check on arrays.

 Such reliability features come at the cost of time efficiency, compared with the simpler and faster C

language which provides the “dangerous” yet efficient pointers.


Quality attributes trade-off

 Tradeoff between scalability and performance.


 Ex: one typical approach to increase the scalability of a service is to replicate servers. To ensure

consistency of all servers (e.g., to make sure that each server has the same logically consistent data),

performance of the whole service is sacrificed.


2. Analysis and selecting software architecture
2. Analysis and selecting software architecture
 Example: Which option should be chosen??
2. Analysis and selecting software architecture

You might also like