Download
1 / 33
330 likes | 341 Views
Software engineering is the science and art of building significant software systems that are on time, on budget, with acceptable performance, and with correct operation. This field is vital as economies rely on software, and more systems are software-controlled. The focus is on cost-effective development, with attention to product attributes such as maintainability, dependability, efficiency, and usability. The software process encompasses activities like specification, design, implementation, validation, evolution, and maintenance. Various process models, such as the waterfall, evolutionary, formal transformation, and reuse-based models, are utilized. The role of software engineers also goes beyond technical considerations, as they have wider ethical, social, and professional responsibilities, especially when developing military systems. Requirements collection and analysis are crucial, as changing requirements are common and require constant validation throughout the software lifecycle. The objectives of requirements analysis are to identify the customer's needs and provide a clear understanding of the system's concepts.
E N D
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
