Download presentation
Presentation is loading. Please wait.
Published byArron May Modified over 9 years ago
1
Software Processes n What is a process? Sequence of steps required to develop or maintain software n Characteristics prescribes major activities utilizes resources, subject to constraints such as schedule, to produce intermediate and final results constraints and controls apply to activities, resources, and products constraints on activities: time, budge, tools controls on activities: config. Mgmt, reports
2
Process should be n Visible: Activities should provide clear indications of progress (deadlines/milestones) n Understandable: Activities and their order of execution are well-defined n Supportable: Automated support for activities is available n Usable: Process is acceptable to and usable by developers
3
Defining Processes n A defined process: facilitates communication about the process provides a basis for process automation facilitates process reuse and evolution aids process management n Elements of process descriptions general description each activity has an entry and exit criteria activities are organized in “sequence” guiding principles explain goals of activities process may contain subprocesses resources, constraints
4
Evolution of Software Process Models n “Code and Fix” model code, test, debug n Problems requirements analysis and design ignored code does not evolve gracefully debugging is difficult Why? Unstructured, spaghetti coding, changes not localized, not modular, difficult to trace, relationships hard to determine
5
SWEng Paradigms for Prescriptive Process Models Chosen based on nature of project, methods, tools used, controls and deliverables required n Linear Sequential Models (Classic or Waterfall, V-shaped) n Prototyping n RAD Model n Evolutionary Process Models (Incremental, Spiral, Concurrent) n Formal Methods n 4GL n Combinations
6
Process Models n Linear Sequential Analysis, design, coding, testing, maintenance Difficulties: Projects rarely follow sequential flow Requirements defined up-front a must (rarely done) Patient customer/no immediate feedback
7
Waterfall Methods and Variants n Phases (similar to develop hardware) Analysis, Design, Code, Test, Maintain n Difficulties projects rarely follow sequential flow requirements defined up-front a must (rarely done) patient customers/no immediate feedback no insight given into how each activity transforms an intermediate product into another n Variants V-shaped model: relationship between types of tests and phases before testing Prototyping variant: requirements and design prototypes
8
Waterfall Model
9
Deliverables n http://www.solovatsoft.com/Development%20 Standard%20Deliverables.pdf http://www.solovatsoft.com/Development%20 Standard%20Deliverables.pdf
10
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10 The V-Model
11
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11 Evolutionary Models: Prototyping Construction of prototype communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback
12
Evolutionary Models: Prototyping n Prototyping quick design, build prototype, evaluate, refine prototype, … engineer product n Prototyping Paper/working subset of features/existing program with some features Requirements, quick design, build prototype, customer evaluation, refine prototype, engineered product Problems: Customer sees prototype, then wants a few fixes quick and delivery Implementation compromises made to get prototype done quickly/forgets compromises and become part of the system
13
Process Models n RAD Model Short development cycle, “high-speed” linear sequential using component-based construction Well understood requirements, constrained scope, IS apps Uses reusable components and 4GLs Problems: Need sufficient human resources for RAD teams Need committed developers and customers Modular system key Not appropriate when technical risks are high (new technology, performance an issue
14
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14 The Incremental Model
15
Incremental/Iterative Development Incremental: functionality developed in pieces Iterative: put in all features, but they are limited
16
Benefits and Problems of Evolutionary Development Incremental: Each build focuses on a subset of functionality, simplifying development Opportunity to learn about problem as design develops customer get a product early and can provide feedback for future builds customer can test software different releases can focus on enhancements that require specialized expertise improperly planned builds result in complex system backward compatibility limits elegance of future releases (and can force hacking) error in basic system architecture may require changes to basic structure that invalidate earlier releases
17
Other Process Models n Transformation (4GLs) Requirements, “design”, implementation using 4GL (specifications into code generator) Advantage Reduces time to produce SW Problems Design/Analysis reduced Some CASE tools produce skeletonized code Limited to certain domains Business IS Compilers (lex, YACC, SDL)
18
Choosing a Process Models n Choice depends on nature of project requirements clearly defined and stable? Pressure to produce a working product quickly? Consequences of operational errors serious? n Classified along a spectrum ranging from radical: all activities carried out in parallel suitable when quick results needed and requirements fuzzy conservative: all activities carried out in a strict sequence with no overlap suitable when consequences of errors serious and requirements are clear and stable n None of the extremes are viable
19
Process Maturity n Processes should be tailored to development environment n The software process maturity framework allows organizations to determine the capabilities of their current processes and establish priorities for improvement
20
CMM Levels n 1- Initial: few defined processes; adhoc; chaotic; success depends on individual effort n 2- Repeatable: cost, schedule, and product tracking processes in place; disciplined process n 3- Defined: Standard process are defined (written down) and used (and enforced) n 4- Managed: Defined process and product qualities are meaningfully measured; predictable n 5- Optimizing: measures used to evaluate/improve process/product
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.