Software Engineering General Project Management Software Requirements

Slides:



Advertisements
Similar presentations
Software Processes.
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Unit 2. Software Lifecycle
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 1 المحاضرة الثانية.
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
ISNE101 Dr. Ken Cosh. Recap  We’ve been talking about Software…  Application vs System Software  Programming Languages  Vs Natural Languages  Syntax,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 1 Project management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
©Ian Sommerville 2000Software Engineering, 6th edition Slide 1 Introduction l Getting started with software engineering l Objectives To introduce software.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 1 COMP201 Project Management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
©Ian Sommerville 2000 Software Engineering, 6th edition Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing.
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7.
7M701 1 Software Engineering Project Management Sommerville, Ian (2001) Software Engineering, 6 th edition Ch. 4
1 SOFTWARE PRODUCTION. 2 DEVELOPMENT Product Creation Means: Methods & Heuristics Measure of Success: Quality f(Fitness of Use) MANAGEMENT Efficient &
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 5 Slide 1 Project management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Project Management Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Chapter 3 Software Processes.
Software Engineering Principles Chapter 3 From Software Engineering by I. Sommerville, Slide 1 project managementorganizing planning scheduling Learning.
©Ian Sommerville 2000Software Engineering, 7th edition. Chapter 5 Slide 1 Chapter 5 Project Management Modified by Randy K. Smith.
Project management DeSiaMore 1.
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter 2 Computer-Based System Engineering As modified by Randy Smith.
Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Chapter 4 Requirements engineering Chapter 4 – Requirements Engineering Lecture 1 1.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Software Processes (Chapter 3)
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
Adaptive Processes © Adaptive Processes Simpler, Faster, Better Software Requirements.
Engineering, 7th edition. Chapter 5 Slide 1 Project management.
1 SWE Introduction to Software Engineering Lecture 4.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000 Slide 1 Project management l Organising, planning and scheduling software projects l Objectives To introduce software project management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Chapter 3 Project Management Chapter 3 Project Management Organising, planning and scheduling software projects.
Requirements Engineering Overview Senior Design Don Evans.
Software Engineering, 8th edition. Chapter 5 1 Courtesy: ©Ian Sommerville 2006 Oct 13 th, 2008 Lecture # 6 Project management.
An Introduction to Software Engineering
Chapter 13: Software Life Cycle Models Omar Meqdadi SE 273 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 Project management. 2 Topics covered Management activities Project planning Project scheduling Risk management.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 3 Slide 1 Project management (Chapter 5 from the textbook)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 1 Project management l Organising, planning and scheduling software projects.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Project management 1/30/2016ICS 413 – Software Engineering1.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 1 Chapter 4: Project management l Organising, planning and scheduling software.
1 Software Requirements Descriptions and specifications of a system.
1 Project management Organising, planning and scheduling software projects.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini II. Software Life Cycle.
Chapter 5 – Requirements Engineering
Presentation transcript:

Software Engineering General Project Management Software Requirements

Software Engineering General Sommerville, Ian (2001) Software Engineering, 6th edition Ch.1-3 http://www.software-engin.com

What is software engineering? Software engineering is an engineering discipline which is concerned with all aspects of software production Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available

What is the difference between software engineering and system engineering? System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process System engineers are involved in system specification, architectural design, integration and deployment

Problems of systems engineering Large systems are usually designed to solve 'wicked' problems Systems engineering requires a great deal of co-ordination across disciplines Almost infinite possibilities for design trade-offs across components Mutual distrust and lack of understanding across engineering disciplines Systems must be designed to last many years in a changing environment

Software and systems engineering The proportion of software in systems is increasing. Software-driven general purpose electronics is replacing special-purpose systems Problems of systems engineering are similar to problems of software engineering Software is (unfortunately) seen as a problem in systems engineering. Many large system projects have been delayed because of software problems

Emergent properties Properties of the system as a whole rather than properties that can be derived from the properties of components of a system Emergent properties are a consequence of the relationships between system components They can therefore only be assessed and measured once the components have been integrated into a system

Systems and their environment Systems are not independent but exist in an environment System’s function may be to change its environment Environment affects the functioning of the system e.g. system may require electrical supply from its environment The organizational as well as the physical environment may be important

System hierarchies This figure shows some of the systems that might be incorporated in an office building. All are sub-systems within the building which is itself a system. the building is located in a street that is in a town. The overall environment is composed of the local environment plus the environment of the containing system. There are two reasons why the environment of a system must be understood by systems engineers. In many cases, the system is intended to make some changes in its environment. therefore a heating system changes its environment by increasing/decreasing its temperature. The correct functioning of the system can therefore only be assessed by the effects on the environment. The functioning of a system can be affected by environmental changes outside the building. Works in the street outside may cut a power cable en the electrical systems is thus disabled.

What is software? Computer programs and associated documentation Software products may be developed for a particular customer or may be developed for a general market

The software process A structured set of activities required to develop a software system Generic activities in all software processes are: Specification Design Validation Evolution

Generic software process models The waterfall model Separate and distinct phases of specification and development Evolutionary development Specification and development are interleaved

Waterfall model

Waterfall model problems Inflexible partitioning of the project into distinct stages This makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood

Evolutionary development Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements

Evolutionary development

Process iteration System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems Iteration can be applied to any of the generic process models Incremental development

Incremental development

What is CASE (Computer-Aided Software Engineering) Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support Upper-CASE Tools to support the early process activities of requirements and design Lower-CASE Tools to support later activities such as programming, debugging and testing

Compare SE with building a house Search for a location Type of the house Make a design (architect) Design  drawings Realization of the house Completion of the house The house in use

Software Engineering Project Management Sommerville, Ian (2001) Software Engineering, 6th edition Ch. 4 http://www.software-engin.com

Project management Organising, planning and scheduling software projects Management activities Project planning Project scheduling Risk management

Software project management Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software

Software management distinctions The product is intangible Software engineering is not recognized as an engineering discipline with the same status as mechanical, electrical engineering, etc. Many software projects are 'one-off' projects

Management activities Proposal writing Project planning and scheduling Project costing Project monitoring and reviews Personnel selection and evaluation

Project planning Probably the most time-consuming project management activity Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget

Project planning process

Activity organization Activities in a project should be organised to produce tangible outputs for management to judge progress Milestones are the end-point of a process activity Deliverables are project results delivered to customers The waterfall process allows for the straightforward definition of progress milestones

Waterfall model

Milestones in the RE process

Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6th edition: Chapter 5 http://www.software-engin.com

Software Requirements Descriptions and specifications of a system

Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process

What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification This is inevitable as requirements may serve a dual function May be the basis for a bid for a contract - therefore must be open to interpretation May be the basis for the contract itself - therefore must be defined in detail Both these statements may be called requirements

Types of requirement User requirements System 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 services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers

Functional and non-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. Non-functional requirements constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Requirements and design In principle, requirements should state what the system should do and the design should describe how it does this In practice, requirements and design are inseparable A system architecture may be designed to structure the requirements The system may inter-operate with other systems that generate design requirements The use of a specific design may be a domain requirement