Software Engineering

Software_Engineering

---

1. What is software engineering?

Software engineering is a systematic, disciplined and quantiable approach to develop a software through requirement definition, design and analysis, programing and implement, release and testing, and mainteinance. Such a procedure is also collaborative, cost-efficient and iterative.

2. General phase of software engineering.

• Requirement definition: communication with user to learn about what users need from software development;
• Design and analysis: design software according to the requirement and create system model from different views;
• Implementation: programing for the system and deploy the system;
• Release and Testing: release the software to its users and test the system according to the requirement;
• Maintainance: maintain the software to make the system continually and well working for its user.

3. Compare waterfall and incremental development process model

• Waterfall model is much eaiser to understand and it focus much on document preparation and design. It assume the requirement is well known before construction.
• Waterfall model doesn't overlapping each stage of development while incremental model activities are sometimes concurrent.
• It costs less of change requirement development and several versions of system can be produced.
• User insight is almost ingored during waterfall model while in incremental model user feedback is important to be review.
• Incremental model can achieve more rapid delivery and deployment to user.

4. Why changes become more costly in later phases of the software engineering?

Because in later phases, any change should cause more work effort than earlier phases. For example, if there is any changes on requirement, only document should be modified if the phase of development still in requirement stage. However, if such a change occurred in later phase like software release, almost all of before work including design and analysis, and implement should be reworked.

5. Generic software product development and commissioned software product

Generic software product development means to develop a software which will be sold to general public who want to use after the software released to market. The specification of what the software should do is owned by the software developer and decisions on software change are made by the developer.

Commissioned software product develpment means to develop a customized software according to specific user requirement from the beginning of development. The specification of what the software should do is owned by the customer for the software and they make decisions on software changes that are required.

6. Why it is important to identify the type of software product and the type of software application?

The type of software product helps us to know the procedure of software such as if we need to communicate with the specific customer;
The type of software application gives us an overview of what the software look like and what technologies should be implied into software system.

7. Why a software project can fail and what is the impact caused by such a failure?

Software can be failed due to a tiny bug or error. For example, Ariane 5 flight 501 was exploded during launching stage, which is caused by a bug in program that a wrong conversion between 64 float value to 16 signed integer.

8. Stakeholder

-is directly affected by the software system
-uses the software
-tests the software
-directly influences software requirements
-install/configures the software
-has financial influence over or financial responsibility for the system
-manages the development team
-is a third party develpoer writing an interface to the system

• Stakeholder with requirement
  User requirement: Client managers, System end-users, Client engineers...
  System requirement: Software developer, System architects, System end-users, Client engineers...

9. What is requirement engineering?

Requirements engineering, is the iterative process of determining user expectations for a new or modified product and establishing the services of the software and the constraints under which it operates and is developed. These features, called requirements, must be quantifiable, relevant and detailed. Deals with understanding the problem that is to be solved and communicating the solution for the problem effectively.

10. The phase of requirement engineering

Requirement elicitation:

• Definition: for software enigineers working with the stake holders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.
• Techniques:
  
  • Interviewing
    
    • Most common
    • Can be formal or informal
    • Types of interviews
      -- Closed interviews based on pre-determined list of questions
      -- Open interviews where various issues are explored with stakeholders.
  • Ethnography,
  • Propotyping,
  • Workshops,
  • Scenarios,
  • Use cases

Requirement analysis:

• Definition:Taking the requirements gathered during the elicitation phase and refining them, ensuring that they possess qualities of good requirements
• Scenarios, Use cases

Requirement specification:

The process of documenting requirements in a document. Have to be understandable by stakeholders who do not have a technical background. May be part of a contract for the system development. Important that these are as complete as possible.

• Advantage of SRS:
  
  • Establish the basis for agreement between the customers and the suppliers on what the software product is to do.
  • Reduce the development effort
  • Provide a baseline for validation and verification
  • Facilitate transfer
  • Facilitate transfer
  • Serve as a basis for enhancement.

Requirement validation:

• Requirements Validation
  Check that the right product is being built. Ensures that the software being developed (or changed) will satisfy its stakeholders. Checks the software requirements specification against stakeholders goals and requirements.

• Requirements Verification
  Check that product is being built right.Ensures that each step followed in the process of building the software yields the right products. Checks consistency of the software requirements specification artefacts and other software development products (design, implementation, ...) against the specification

11. Validation vs Verification

Validation: checks that the product design satisfies or fits the intended use. The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. Develop the right software.

Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Develop the software right.

11. 10 Requirements Traps to Avoid

• Confusion Over “Requirements”
• Inadequate Customer Involvement
  Not all stakeholder is considered during requirement engineering. That may lead to some missing requirement and the software may not be complete.
• Vague and Ambiguous Requirements: If there are some ambiguous word appeared in requirement document, the requirement statement may have several different meanings with multiple readers interpret.
• Unprioritized Requirements
• Building Functionality No One Uses
  User doesn't clearly know what they need and declare some functions are needed which in fact is uneccessary.
• Analysis Paralysis
• Scope Creep
• Inadequate Change Process
  Sometime the suggested changes may be accepted without carefully thinking. The change might turn out to be more complex than anticipated, take longer than promised, be technically or economically infeasibale.
• Insufficient Change Impact Analysis
• Inadequate Version Control

12. Software Design

Interface: that means designing the interface of software like mobile device interface;
Architectural: designning the architetural
Communication, Components, Database

13. Software Engineering Activities

Risk Assessment; Reviews; Design; Architecture; Modeling; Simulation; Prototyping; Management; Evolution; Testing; Coding; Documentation; Marketing; Operations; Maintenance; Support; Demonstration; Requirements; Training

14. Management Activities

• Proposal writing
• Project planning and scheduling
• Project costing
• Project monitoring and reviews
• Personnel selection and evaluation
• Report writing and presentations

15. Software prototyping

A prototype is an initial version of a system used to demonstrate concepts and try out design options.
A prototype can be used in: Requirements, Design, Testing.

16. Types of Requirements

• Functional
  
  • Services that the software provides, how the system should react to particular inputs and how the system should behave in particular situations.
  • May also be what the system should NOT do
• Non-Functional
  
  • Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
  • Often apply to the system as a whole rather than to individual features or services.
• User requirements/Features
  
  • Goals or tasks that the user must be able to perform with the system.
  • High level
  • Expressed via use cases, scenarios, etc.
• System Requirements
  
  • Decomposed from user requirements
  • Explain in detail what the system should do to meet the user requirements
• Business Requirements
  
  • Apply to a person, process, organization
  • Defines some aspect of business
    
    • Increase profit by N%
    • Reduce maintenance costs
• Business Rules
  
  • Restricts users to specific conditions
    
    • Conform
    • Comply
    • According to
• Interface Requirements
  
  • Requirements for external interfaces that the system interacts with.

17, Good quanlity of requirement

• Unitary (Cohesive):The requirement addresses one and only one thing.
• Non-Conjugated (Atomic): The requirement is atomic, i.e., it does not contain multiple requirements.
• Unambiguous: The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage.It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided.
• Complete: The requirement is fully stated in one place with no missing information.
• Consistent: The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

18. Testing

Testing will never eliminate problems completely, but it can reduce the number of problems (Recurring theme in Software Engineering).
Testing increases the confidence in the software. Technically, once the software is shipped, the testing phase ends, but really testing is an ongoing activity throughout all phases

Stages of Testing:

• Development or compenent testing
  
  • Individual components are tested independently
  • Components may be functions or objects or coherent groupings of these entities.
• System testing
  
  • Testing of the system as a whole. Testing of emergent properties is particularly important.
• Acceptance testing
  
  • Testing with customer data to check that the system meets the customer’s needs.

Testing Techniques

• Who
  
  • Programmers
  • Testers (QA)
  • Users
• What is tested
  
  • Unit testing
  • Functional testing
  • Integration/system testing: is testing the interactions between components
  • User interface testing
• Why test
  
  • Acceptance
  • Conformance
  • Configuration
  • Performance, stress
• How (Test cases: A set of inputs and expected outputs/outcomes used to determine if the software is working and/or behaving correctly)
  
  • Intuition
  • Specification based (black box)
  • Code based (white-box)
  • Existing cases (regression: testing the system to check that changes have not 'broken' previously working code.)
  • Faults

Testing is a tradeoff between: Budget, Schedule, Quality

19. Black-Box and White-Box Testing

Black Box testing treats the software as a black box, that is we give the software an input and expect an output. The internal structure and design of the software may not be known and is not necessary to generate test cases. Data driven, input/output driven and requirements driven testing are terms also used for black box testing.
White box testing depends on knowing the internal software structure and flow.
Tests cases are created for each independent linear path.(Cyclomatic complexity)
Glass-box testing, design driven and logic based testing are terms also used for white box testing.

20. User Testing

User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing. User testing is essential, even when comprehensive system and release testing have been carried out.

• Alpha testing
  Users of the software work with the development team to test the software at the developer's site.
• Beta testing
  A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
• Acceptance testing
  Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment.

21. Cohesion and Coupling

• Cohesion:
  
  • 偶然内聚性（Coincidental cohesion，最低）
    偶然内聚性是指模块中的机能只是刚好放在一起，模块中各机能之间唯一的关系是其位在同一个模块中（例如：“工具”模块）。
  • 逻辑内聚性（Logical cohesion）
    逻辑内聚性是只要机能只要在逻辑上分为同一类，不论各机能的本质是否有很大差异，就将这些机能放在同一模块中（例如将所有的鼠标和键盘都放在输入处理副程序中）。
  • 时间性内聚性（Temporal cohesion）
    时间性内聚性是指将相近时间点运行的程序，放在同一个模块中（例如在捕捉到一个异常后调用一函数，在函数中关闭已打开的文件、产生错误日志、并告知用户）。
  • 程序内聚性（Procedural cohesion）
    程序内聚性是指依一组会依照固定顺序运行的程序放在同一个模块中（例如一个函数检查文件的权限，之后打开文件）。
  • 联络内聚性（Communicational cohesion）
    联络内聚性是指模块中的机能因为处理相同的数据，因此放在同一个模块中（例如一个模块中的许多机能都访问同一个记录）。
  • 依序内聚性（Sequential cohesion）
    依序内聚性是指模块中的各机能彼此的输入及输出数据相关，一模块的输出数据是另一个模块的输入，类似工厂的生产线（例如一个模块先读取文件中的数据，之后再处理数据）。
  • 功能内聚性（Functional cohesion，最高）
    功能内聚性是指模块中的各机能是因为它们都对模块中单一明确定义的任务有贡献（例如XML字符串的词法分析）。
• Coupling:
  
  • 内容耦合（content coupling，耦合度最高）
    也称为病态耦合（pathological coupling）是指一个模块依赖另一个模块的内部作业（例如，访问另一个模块的局域变量），因此修改第二个模块处理的数据（位置、形态、时序）也就影响了第一个模块。
  • 共用耦合（common coupling）
    也称为全局耦合（global coupling.）是指二个模块分享同一个全局变量，因此修改这个共享的资源也就要更动所有用到此资源的模块。
  • 外部耦合（external coupling）
    发生在二个模块共用一个外加的数据格式、通信协议或是设备界面，基本上和模块和外部工具及设备的沟通有关。
  • 控制耦合（control coupling）
    是指一个模块借由传递“要做什么”的信息，控制另一个模块的流程（例如传递相关的旗标）。
  • 特征耦合（stamp coupling）
    也称为数据结构耦合，是指几个模块共享一个复杂的数据结构，而每个模块只用其中的一部份，甚至各模块用到的部份不同（例如传递一笔记录给一个函数，而函数只需要其中的一个字段。
  • 数据耦合（data coupling）
    是指模块借由传入值共享数据，每一个数据都是最基本的数据，而且只分享这些数据（例如传递一个整数给计算平方根的函数）。
  • 消息耦合（message coupling，是无耦合之外，耦合度最低的耦合）
    可以借由以下二个方式达成：状态的去中心化（例如在对象中），组件间利用传入值或消息传递 (计算机科学)来通信。
  • 无耦合
    模块完全不和其他模块交换信息。