We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byAmari Hollifield
Modified over 5 years ago
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 2- Software Process Models and Project Management Dr Richard Clayton & Dr Marian Gheorghe Module (1 st part) homepage http://www.dcs.shef.ac.uk/~marian
2COM6030 Systems Analysis and Design © University of Sheffield 2005 Outline Software engineering models Software process models: waterfall, evolutionary, formal development, reuse/component development Management spectrum Software teams Managing people, project, product and processes Reading: Sommerville chapter 3; Pressman chapter 2
3COM6030 Systems Analysis and Design © University of Sheffield 2005 Software Engineering Problems SE deals with practical problems Complex software products (I) Processes (II) Methods/Models (III) People (IV)
4COM6030 Systems Analysis and Design © University of Sheffield 2005 (III) SE models Models are used to abstractly represent various processes, activities, entities etc. SE process models: Architectural perspective Flow of activities Linear vs iterative Software processes depend on project type, complexity aspects, technology, budget, people knowledge Models of various activities (specification, design), entities (data, transformations)
5COM6030 Systems Analysis and Design © University of Sheffield 2005 SE process models SE process models: Waterfall key for MAXI project Evolutionary Formal system development Reuse/Component-based Iterative Incremental Spiral Others
6COM6030 Systems Analysis and Design © University of Sheffield 2005 First part of the course Waterfall model maps linearly fundamental activities Waterfall model Requirements analysis and definition System and software design Implementing and unit testing Integration and system testing Operation and maintenance
7COM6030 Systems Analysis and Design © University of Sheffield 2005 Waterfall: +’s and –’s Advantages: Help project management, documentation Complex systems are well-defined and structured Reflects engineering practice Encourages a discipline of modelling Limitations Often stages overlap Rather inflexible Imposes early commitments to rigid requirements set Impossible to deal with changes
8COM6030 Systems Analysis and Design © University of Sheffield 2005 Evolutionary development Initial implementation refined into final system Exploratory development: the system evolves through stages into a final software product Throw-away prototyping Advantages: Flexible and suitable for small systems Helps in early stages or when little information known about a system Limitations: Process is not visible Poorly structured systems Special tools/techniques required Initial version Intrm versions Final version
9COM6030 Systems Analysis and Design © University of Sheffield 2005 Formal systems development An approach based on formal mathematical transformations of a set of system specifications into an executable program; it consists of: Requirements definition Formal specification Formal transformation Integration and system testing Refinement sequence Advantages Precise and error-free Suitable for safety-critical systems Correctness proofs Limitations Require specialised expertise No obvious quality over other non-formal approaches Introduce extra-complexity …
10COM6030 Systems Analysis and Design © University of Sheffield 2005 Reuse-oriented development Reuse of components from other projects; essential in evolutionary approach; it consists of Component analysis – already existing components identified Requirements modification – requirements vs information about components System design and reuse – design framework vs existing design Development and integration – new components integrated with existing frameworks/templates Advantages: Rapid and efficient development process Reduces costs and risks Limits Systems that do not meet real expectations Loose control over the inherited components
11COM6030 Systems Analysis and Design © University of Sheffield 2005 Iterative development Complex software systems require hybrid approaches (combination of various models) and iterations over certain stages Incremental development Outline requirements Assign requirements to increments Define system architecture Develop increment Validate increment Integrate increment Validate (partial) system Final system Advantages Gap between system specification and system delivery is reduced Early increments may be used as prototypes Lower risk of project failure Highest priority services delivered first Limitations Increments should be small Difficult to map customer’s requirements into increments
12COM6030 Systems Analysis and Design © University of Sheffield 2005 Spiral development The software process instead of being a sequence of activities is now a spiral; each loop of the spiral represents a phase of software process; each loop has four components: Objective setting – specific objectives defined Risk assessment and reduction Development and validation – an appropriate model is considered Planning – when a new phase is requested
13COM6030 Systems Analysis and Design © University of Sheffield 2005 Other models Rapid Application Development (RAD) – an incremental software development process model emphasizing on a very short development cycle; useful when requirements are well-understood, modular Concurrent development model represents associated activities as states in a concurrent statecharts – it is a paradigm for client/server applications XP (agile)
14COM6030 Systems Analysis and Design © University of Sheffield 2005 Management spectrum Software engineering management refers to four P’s: people, product, process and project People: Key players in software projects: senior managers project (technical) managers practitioners customers end-users Software team (practitioners) Team organization (skills, cohesion) Team communication
15COM6030 Systems Analysis and Design © University of Sheffield 2005 Software teams Software team should have: A long/medium/short term plan (+recovery) A good mixture of skills (management, client interaction, technical, analysis, design, modelling) and should rely on A coherent set of documents corresponding to software processes (analysis, design, test) and team activities (minutes, agendas, tasks, plans, charts)
16COM6030 Systems Analysis and Design © University of Sheffield 2005 Software product management Requires quantitative estimates and an organized plan (mostly when solid information is unavailable !). Software scope is defined (context, objectives, function and performance) Problem decomposition
17COM6030 Systems Analysis and Design © University of Sheffield 2005 Software process management The suitable process model is decided for The customers requesting the product The characteristics of the product The project environment Actions Preliminary plan developed Process decomposition
18COM6030 Systems Analysis and Design © University of Sheffield 2005 Software project management Software project management requires assessing the risks involved and understanding the problems that may threaten the project; 10 facts undermining a project Software people don’t understand customer’s needs The project scope poorly defined Changes poorly managed The technology changes Business is changing Unrealistic deadlines Resistant users Losing the sponsorship Lack of skilled people in software team Managers/Practitioners do not use best practices
19COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary Software engineering processes and their associated models are presented. Software life cycle is represented in different modelling paradigms. Management spectrum of activities covering people, product, processes and project, is discussed. The role of software teams is emphasized. Learned about the need of modelling and using an engineering approach to software production.
Prescriptive Process models
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
Lecture # 2 : Process Models
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 المحاضرة الثانية.
Software Processes Modified by Randy K. Smith
CS487 Software Engineering Omar Aldawud
Chap 2. Software Processes
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
CSE 470 : Software Engineering The Software Process.
COMP 474 Software Engineering Professor William L. Honig.
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.
© Ian Sommerville A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.
Software Engineering COMP 201 1COMP201 - Software Engineering Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP.
ISNE101 Dr. Ken Cosh. Recap We’ve been talking about Software… Application vs System Software Programming Languages Vs Natural Languages Syntax,
Chapter 2 – Software Processes Lecture 1 1Chapter 2 Software Processes.
© 2020 SlidePlayer.com Inc. All rights reserved.