[소프트웨어] 소프트웨어공학 정리

본 글은 학교 수업(박지현 교수님의 소프트웨어공학)을 듣고 복습차 정리한 글입니다.

1. Software Engineering

software: Computer programs and associated documentation

attributes of good software: Maintainability (evolve to meet the changing needs of customers/changing needs of customers), Dependability and security(not cause physical or economic damage in the event of system failure), Efficiency(not make wasteful use of system resources /responsiveness, processing time, memory utilisation), Acceptability(acceptable to the type of users understandable, usable and compatible)

Software engineering: engineering discipline that is concerned with all aspects of software production/adopt a systematic and organized approach/an engineering discipline whose focus is the cost-effective development of high-quality software systems./practicalities of developing and delivering useful software/ part of this process concerned with developing the software infrastructure, control, applications and databases in the system

Computer engineering: theory and fundamentals/ insufficient to act as a complete underpinning for software engineering

System engineering: concerned with all aspects of computer-based systems development

 

1. Project Planning (have to get Products(outcome), role(responsibilities of people), pre-and post- condition(before and after a process activity has been enacted or a product produced))

Proposal stage: bidding for a contract to develop/provide a software system

Software Pricing (Factors: Market Opportunity(accepting a low profit on one project may give the organization the opportunity to make a greater profit later), Contractual terms(retain ownership of the source code), Requirements Volatility(if requirements are likely to change, an organization may lower its price to win a contract, high prices can be charged for changes to the requirements), Financial Health(Developers in financial difficulty may lower their price to gain a contract))

Cost Estimation (Experience-based techniques/Algorithmic cost modeling)

Effort = A * Size^B * M (A: organisation-dependent constant, B: disproportionate effort for large projects, M: multiplier reflecting product, process and people attributes, Development effort multiplier /Nominal effort(A *size^B)) commonly used product attribute is code size / Code size = AVC * number of function points

Line of Code (Factors: Use of COTS and components, Programming language), assume linear btw system size and volume of documentation, Measures of productivity based on LOC suggest that programmers who write verbose code are more productive than programmers who write compact code.

FP= UFP(sum(number of elements of given type)*(weight))) * TCP (0.65+0.01*DI(factor 가중치합))

COCOMO model (81: person per month) 

 

Project startup phase = Plan-driven development(record work, who,schedule and product)

Pros: The arguments in favor of a plan-driven approach are that early planning allows organizational issues(availability of staff, other projects) to be closely taken into account, that potential problems and dependencies are discovered before the project starts.

The principal argument against plan-driven development is that many early decisions have to be revised because of changes to the environment in which the software is to be developed and used.

Project plan supplements: Quality plan(quality procedures and standards), Validation plan(approach, resources and schedule), Configuration management plan, Maintenance plan(maintenance requirements, costs and efforts), Staff development plan

Project scheduling activities: Split project into tasks, estimate time and resources/Organize task concurrently, Minimize task dependencies

Periodically throughout the project: modify = Project Planning

Bar charts(Gantt chart): against calendar time

Activity charts: task dependencies and critical path(minimum time /longest path)

 

1. Project Process Models

Waterfall model: separate identified phase

Problems: Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

Appropriate: when the requirements are well-understood and changes will be fairly limited during 

the design process. Mostly used for large systems engineering projects where a system is developed at several sites.(the plan-driven nature of the waterfall model helps)

Incremental Development model

Pros: The cost of accommodating changing customer requirements is reduced. (the amount of analysis and documentation that has to be redone is much less than is required with the waterfall model)/ It is easier to get customer feedback on the development work that has been done. (customers can comment on demonstrations of the software and see how much has been implemented.)/ More rapid delivery and deployment of useful software to the customer is possible(Customers are able to use and gain value from the software earlier than is possible with a waterfall process.)

Cons: The process is not visible. (Managers need regular deliverables to measure progress. However, if systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.)/ System structure tends to degrade as new increments are added.(Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.)

Reuse-oriented software engineering model

Based on systematic reuse where systems are integrated from existing components or COTS

Pros: Reducing the amount of software to be developed/ Reducing cost/ Leads to faster delivery of the software.

Cons: Requirements compromises are inevitable/ Leads to a system that does not meet the real need of users.

Boehm’s spiral model Process is represented as a spiral rather than as a sequence of activities with backtracking.• Each loop in the spiral represents a phase in the process.• (Risk-driven approach)Risks are explicitly assessed and resolved throughout the process./Objective setting>Risk assessment and reduction>Development and validation>Planning

 

1. Project Process

Software Specifications: the process of establishing what services are required and the constraints

Requirement: what system should do/high-level abstract statement~detailed functional specification /may also be specified programming language or development method.

Requirement checking: Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked?

User requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

System requirements: A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor./ Functional requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do./ Non-functional requirements: 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 individual features or services. define system properties and constraints (reliability, response time and storage requirements). May be more critical than functional requirements.

Domain requirements Constraints on the system from the domain of operation/ Problems: Requirements are expressed in the language of the application domain This is often not understood by software engineers developing the system, Domain Specialists understand the area so well that they do not think of making the domain requirements explicit / Problems of natural language: Lack of clarity(Precision is difficult without making the document difficult to read), Requirement confusion(Functional and non-functional requirements tend to be mixed up), Requirement amalgamation (Several different requirements may be expressed together.)

SW requirement document: is not a design document, set of WHAT the system should do

Requirement Elicitation and Analysis/ Problems: Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change. / Stages for requirements elicitation and analysis include: Requirements discovery, Requirements classification and organization,Requirements prioritization and negotiation, Requirements specification./ Interviewing: Types of interview: Closed interviews based on predetermined list of questions, Open interviews where various issues are explored with stakeholders, Normally a mix of closed and open-ended interviewing. + Effective interviewing: Be open-minded, avoid preconceived ideas about the requirements and are willing to listen to stakeholders. Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.

Requirements Validation: Concerned with demonstrating the requirements define the system that

the customer really wants. Requirements error costs are high so validation is very important. (Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an  implementation error)/ Requirements reviews:Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage./ Prototyping

Requirement Management: the process of managing changing requirements during the requirements engineering process and system development./keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes.need to establish a formal process for making change proposals and linking these to system requirements.

Software Design & Implementation: are closely related and may be interleaved.

Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed./ Interface design, where you define the interfaces between system components. /Component design, where you take each system component and design how it will operate./ Database design, where you design the system data structures and how these are to be represented in a database.

Software Verification & Validation: show that a system conforms to its specification and meets the requirements of the system customer. involves checking and review processes and testing.

Software Evolution: Coping with change 

Change is inevitable: Business changes lead to new and changed system requirements/ New technologies open up new possibilities for improving implementation./ Changing platforms require application changes./ Plan changes are inevitable: the plan of reflect requirements, schedule and risk changes./ Changing business goals

Incremental Delivery: broken down into increments. highest priority requirements are included in early increments./ Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

A prototype system: an initial version of a system used to demonstrate concepts and try out design options. / focus on functional & the product that are not well-understood. Error checking and recovery may not be included in the prototype / Can be used in: requirements engineering process to help with requirements elicitation and validation. In design processes to explore options and develop UI design / Benefits: a closer match to users’ real need ( a prototype system may be developed to show some key features of the system to customers), Improved system usability, design quality. Reduced development effort / Throw-away Prototype: Prototypes should be discarded after development as they are not a good basis for a production system: – It may be impossible to tune the system to meet non-functional requirements; – Prototypes are normally undocumented;– The prototype structure is usually degraded through rapid change;– The prototype probably will not meet normal organizational quality standards.