Software Engineering
E N D
Presentation Transcript
Software Engineering • Software Engineering is the science and art of • building significant software systems that are: • 1) on time • 2) on budget • 3) with acceptable performance • 4) with correct operation.
Software Engineering • The economies of all developed nations are dependent on software. • More and more systems are software controlled. • Software engineering is concerned with theories, methods and tools for professional software development.
Software Costs • Software costs often dominate system costs. The costs of software on a PC are often greater than the hardware cost. • Software costs more to maintain than it does to develop. • Software engineering is concerned with cost-effective software development.
Software Products • Generic products: • Stand-alone systems which are produced by a development organization and sold on the open market to any customer. • Customized products: • Systems which are commissioned by a specific customer and developed specially by some contractor.
Software Product Attributes • Maintainability • Dependability • Efficiency • Usability
Importance of Product Characteristics • The relative importance of these characteristics depends on the product and the environment in which it is to be used. • In some cases, some attributes may dominate • In safety-critical real-time systems, key attributes may be dependability and efficiency. • Costs tend to rise exponentially if very high levels of any one attribute are required.
The Software Process • Structured set of activities required to develop a software system • Specification • Design • Implementation • Validation • Evolution • Activities vary depending on the organization and the type of system being developed. • Must be explicitly modeled if it is to be managed.
Engineering Process Model • Specification: Set out the requirements and constraints on the system. • Design: Produce a model of the system. • Manufacture: Build the system. • Test: Check the system meets the required specifications. • Install: Deliver the system to the customer and ensure it is operational. • Maintain: Repair faults in the system as they are discovered.
Software Engineering is Different • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of the system for testing. • Software does not wear out - maintenance does not mean component replacement.
Generic Software Process Models • Waterfall • Separate and distinct phases of specification and development • Evolutionary • Specification and development are interleaved • Formal Transformation • A mathematical system model is formally transformed to an implementation • Reuse-based • The system is assembled from existing components
Process Model Problems • Waterfall • High risk for new systems because of specification and design problems. • Low risk for well-understood developments using familiar technology. • Prototyping • Low risk for new applications because specification and program stay in step. • High risk because of lack of process visibility. • Transformational • High risk because of need for advanced technology and staff skills.
Hybrid Process Models • Large systems are usually made up of several sub-systems. • The same process model need not be used for all subsystems. • Prototyping for high-risk specifications. • Waterfall model for well-understood developments.
Professional Responsibility • Software engineers should not just be concerned with technical considerations. They have wider ethical, social and professional responsibilities. • No clear rights and wrongs about many of these issues: • Development of military systems
Requirements Collection User requirements are often expressed informally: • features • usage scenarios Although requirements may be documented in written form, they may be incomplete, ambiguous, or even incorrect.
Changing requirements Requirements will change! • inadequately captured or expressed in the first place • user and business needs may change during the project Validation is needed throughout the software lifecycle, not only when the “final system” is delivered! • build constant feedback into your project plan • plan for change • early prototyping [e.g., UI] can help clarify requirements
Requirements Analysis and Specification Analysis is the process of specifying what a system will do. • The intention is to provide a clear understanding of what the system is about and what its underlying concepts are. The result of analysis is a specification document. Does the requirements specification correspond to the users’ actual needs?
Analysis Objectives • Identify customer’s needs. • Evaluate system for feasibility. • Perform economic and technical analysis. • Allocate functions to system elements. • Establish schedule and constraints. • Create system definitions.
Software Requirements Analysis Phases • Problem recognition • Evaluation and synthesis • focus is on what not how • Modeling • Specification • Review
Feasibility Study • Economic feasibility • cost/benefit analysis • Technical feasibility • hardware/software/people, etc. • Legal feasibility • Alternatives • there is always more than one way to do it
Types of Requirements - 1 • Functional requirements: • input/output • processing. • error handling. • Non-functional requirements: • Physical environment (equipment locations, multiple sites, etc.). • Interfaces (data medium etc.). • User & human factors (who are the users, their skill level etc.).
Types of Requirements - 2 • Non-functional requirements (continued): • Performance (how well is system functioning). • Documentation. • Data (qualitative stuff). • Resources (finding, physical space). • Security (backup, firewall). • Quality assurance (max. down time, MTBF, etc.).
Requirement Validation • Correct? • Consistent? • Complete? • Externally - all desired properties are present. • Internally - no undefined references. • Each requirement describes something actually needed by the customer. • Requirements are verifiable (testable)? • Requirements are traceable.
Software Requirements Elicitation • Customer meetings are the most commonly used technique. • Use context free questions to find out • customer's goals and benefits • identify stakeholders • gain understanding of problem • determine customer reactions to proposed solutions • assess meeting effectiveness • Interview cross section of users when many users are anticipated.
Object-Oriented Analysis An object-oriented analysis results in models of the system which describe: • classes of objects that exist in the system • responsibilities of those classes • relationships between those classes • use cases and scenarios describing • operations that can be performed on the system • allowable sequences of those operations ESE — Introduction
Prototyping (I) A prototype is a software program developed to test, explore or validate a hypothesis, i.e. to reduce risks. An exploratory prototype, also known as a throwaway prototype, is intended to validate requirements or explore design choices. • UI prototype — validate user requirements • rapid prototype — validate functional requirements • experimental prototype — validate technical feasibility ESE — Introduction
Prototyping (II) An evolutionary prototype is intended to evolve in steps into a finished product. • iteratively “grow” the application, redesigning and refactoring along the way First do it, then do it right, then do it fast. ESE — Introduction
Design Design is the process of specifying how the specified system behaviour will be realized from software components. The results are architecture and detailed design documents. Object-oriented design delivers models that describe: • how system operations are implemented by interacting objects • how classes refer to one another and how they are related by inheritance • attributes and operations associated to classes Design is an iterative process, proceeding in parallel with implementation! ESE — Introduction
