COMP 325 Lecture 1: Scope of Software Engineering
major resources: Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008.

[ schedule | next ]

Software Engineering

• Schach: discipline whose aim is production of fault-free software, delivered on time and within budget, that satisfies the client's needs.
• Sommerville: structured approach to designing, building and maintaining large software systems
• Lethbridge : process of solving customers' problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints
• IEEE : the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software
• Wikipedia (13 Sep 2010) : a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build

Multi-faceted

• risk: degree of uncertainty. SE considers three major categories: technical, schedule, budget
• historical: 1968 SE Conference declaration of software crisis with engineering approach as solution
• historical: major study in 2001 reveals 28% of software development projects successful (works, on time, w/i budget), 49% delivered but deficient, 23% canceled before delivery.
• economic: development decisions may involve complex economics. Consider these examples:
  • offshoring programming tasks
  ,
  • adoption of new specification technique or programming language,
  • "adding personnel to a late project only makes it later" (Brooks)
• life cycle phases: classical phases include requirements, analysis,
design, implementation, postdelivery maintenance, retirement. Many studies have considered the relative efforts that each require, and the cost of repairing faults detected along the way.
• teams: project size and schedule usually dictates team solution. If one person can develop it in one year, can a team of six develop it in two months? Consider the overhead involved and opportunities for error.
• organizations: ACM, IEEE-CS, ISO (International Organization for Standardization)
• ethics: major codes of ethics governing software engineers are
  • Software Engineering Code of Ethics and Professional Practice, developed by ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional Practices. See http://www.acm.org/serving/se/code.htm
  ACM Code of Ethics and Professional Conduct, see http://www.acm.org/constitution/code.html

Classical Phases

• requirements: find out what the client needs
• analysis: analyze client needs and document in specification. Focus is on client and problem domain and terminology
• design: determine solution framework (architecture) and design its components. Focus shifts to solution domain and terminology
• implementation: coding, integration and testing. Deliver upon completion.
• postdelivery maintenance: changes, which fall into three categories: corrective (repair faults), perfective (improve features), adaptive (adapt to new environment). Total cost can be 3 times development cost. Paradoxically, good software may have higher maintenance costs than poor software because it is used!
• retirement: removed from service

Comments on Phases

• There is not a planning phase because planning is done during multiple phases. Particularly in the period prior to design.
• There is not a testing phase because testing is done during multiple phases. The sooner a fault is detected, the less expensive it is to fix. Studies show exponential growth. Consider a requirements fault not discovered until delivery...
• There is not a documentation phase because documentation is done during multiple phases. Documentation serves as progress marker, blueprint for next phase, source of test data, shared information resource for project personnel.
• Modern definitions of maintenance include maintenance activities, such as correcting faults, that occur during development prior to delivery. Author calls this (modern) maintenance.

Classical vs. Object-Oriented paradigm

• paradigm refers to a model for framing the way you think about complex things
• classical paradigm refers to the structured approach, developed during the 1970s and 1980s.
  • Practices include structured analysis, structured design, structured programming, etc.
  • Does not scale up well to hyper-sized products, usually measured by lines of code (LOC)
  • Practices usually consider operations and data separately. Dataflow Diagrams (DFD), despite the name, focus on operation sequences. Entity-Relation Diagrams (ERD) focus on data structures.
  • These are important and we will study and use them
• object-oriented paradigm refers to an approach developed during the 1980s and 1990s.
  • Practices include object-oriented analysis, object-oriented design, object-oriented programming, etc.
  • Practices combine operations and data into objects.
  • Encapsulation in particular distinguishes OO from structured. In a structured approach, the data are exposed to ANY operations which may want to use or misuse them. In the OO approach, the data are accessible to external operations only through defined methods.
• Object-oriented life cycle comprises similar kinds of activities as classical, but they are called workflows rather than phases. "Phase" carries a sense of sequentiality. "Workflows" can be done concurrently.