1 / 21

Software Process Models

Software Process Models. Lawrence Chung Software Engineering. What is a Process?. Given input , transform s it into output Consist of a set of activities Ordering among the activities (a partial order) Software Process Also called methodology sometimes People are everything

hina
Download Presentation

Software Process Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Process Models Lawrence Chung Software Engineering

  2. What is a Process? • Given input, transforms it into output • Consist of a set of activities • Ordering among the activities (a partial order) • Software Process • Also called methodology sometimes • People are everything • Involves use of “resources”, such as ??? • Software process models ~~ software lifecycle models • Process descriptions are also specifications • Should be as complete, consistent and clear

  3. Why Software Process? Quality of product Quality of Process • Garbage in garbage out, so get the right requirements Good Process: Input -> Software Input -> Software Bad Process: Input -> Software Input -> Software P r o c e s s • thru garbage, garbage out, so get the right process Product So, know the input sources, specify process & specify product

  4. Software lifecycle models:Generic software process models • The waterfall model • Separate and distinct phases of specification and development • Incremental development (w. evolutionary) • Each increment represents one functionality; • Specification and development can be interleaved • The Spiral model • Each loop in the spiral represents an incremental phase in the process. • Formal systems development • A mathematical system model is formally transformed to an implementation • Reuse-based development • The system is assembled from existing components

  5. Waterfall model 1 [aka Royce1970] Separate and distinct phases of specification and development Systems Engineering Software Req. Analysis Operation/Maintenance Project Planning Design Implementation Testing/Verification Release

  6. Waterfall model 2 [Sommerville2000]

  7. Waterfall model – pros and cons • Inflexible partitioning of the project into distinct stages • This makes it difficult to respond to changing customer requirements • This model is only appropriate when the requirements are well-understood • Big design up front - time spent early on making sure that requirements and design are correct is very useful in economic terms (it will save you much time and effort later) • Simplicity and controllability

  8. Incremental development • Development and delivery is broken down into increments • Each increment delivers part of the required functionality • Requirements are prioritised and the highest priority requirements are included in early increments • Once the development of an increment is started, the requirements are frozen • Requirements for later increments can continue to evolve

  9. Incremental development advantages • System functionality is available earlier and customer does not have to wait as long • Early increments act as a prototype to help elicit requirements for later increments • Lower risk of overall project failure • The highest priority system services tend to receive the most testing

  10. Spiral development • Process is represented as a spiral rather than as a sequence of activities with backtracking • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design- loops in the spiral are chosen depending on what is required • Risks are explicitly assessed and resolved throughout the process

  11. D e t e r m i n e o b j e c t i v e s E v a l u a t e a l t e r n a t i v e s a l t e r n a t i v e s a n d i d e n t i f y , r e s o l v e r i s k s c o n s t r a i n t s R i s k a n a l y s i s R i s k a n a l y s i s R i s k O p e r a - a n a l y s i s P r o t o t y p e 3 t i o n a l p r o t o y p e P r o t o t y p e 2 Risk P r o t o - anal ysis R E V I E W t y p e 1 R e q u i r e m e n t s p l a n S i m u l a t i o n s , m o d e l s , b e n c h m a r k s L i f e - c y c l e p l a n C o n c e p t o f O p e r a t i o n S / W P r o d u c t r e q u i r e m e n t s D e t a i l e d d e s i g n d e s i g n R e q u i r e m e n t D e v e l o p m e n t v a l i d a t i o n p l a n C o d e U n i t t e s t D e s i g n I n t e g r a t i o n V & V I n t e g r a t i o n a n d t e s t p l a n P l a n n e x t p h a s e t e s t A c c e p t a n c e t e s t D e v e l o p , v e r i f y S e r v i c e n e x t - l e v e l p r o d u c t Spiral model

  12. Formal systems development • Based on the transformation of a mathematical specification through different representations to an executable program • Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification • Embodied in the ‘Cleanroom’ approach to software development • No need to test for defects

  13. Formal systems development

  14. Formal systems development • Problems • Need for specialised skills and training to apply the technique • Difficult to formally specify some aspects of the system such as the user interface • Changes require new transformations and proofs • Typically does not scale • Applicability • Critical systems (e.g., in terms of safety or security)

  15. Reuse-oriented development • Based on systematic reuse where systems are integrated from existing components or COTS systems • Process stages • Component analysis • Requirements modification • System design with reuse • Development and integration • Becoming important but still limited experience with it

  16. Extreme programming • New approach to development based on the development and delivery of very small increments of functionality • Relies on constant code improvement, user involvement in the development team and pairwise programming • Recently included into ‘agile methods’ since ‘extreme’ had a negative connotation

  17. Capability Maturity Model [SEI] • Developed in 1986 with leadership from the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU), CMU-SEI. • For assessing and improving software processes • As a guidance for measuring software process maturity Continuously Improving process 5 - Optimizing Predictable process 4 - Managed Standard, Consistent process 3- Defined 2 - Repeatable Disciplined process 1 - Initial

  18. Some CMM Observations… • The number of companies using CMM to assess their software management practices more than doubles every 5 years • Software Quality Assurance is the biggest obstacle for organizations trying to move from level 1 to level 2. • Organization Process Definition is one of the biggest obstacles for organization trying to move from level 2 to level 3. • On average, it takes an organization: • 25 months to move from level 1 to 2 • 22 months to move from level 2 to 3 • 36.5 months to move from level 3 to 4 • Only 1.2% of companies engaged in CMM have IT departments with over 2000 employees. Of these large companies, 40% are at CMM levels 3, 4 or 5. • About 80% of companies engaged in CMM have IT departments with less than over 300 employees. Of these smaller companies, 21% are at CMM levels 3, 4, or 5. • About 1/3 of companies engaged in CMM are located overseas (primarily India), and are 3 times more likely to reach CMM level 4 or 5 than US organizations. • Only about 23% of organizations surveyed eventually move from level 2 to level 3 or higher.

  19. Quantitatively Managed (4) Optimizing (5) Defined (3) Managed (2) Initial (1) CMMI-SE/SW/IPPD/SS - Staged Focus • Organizational Innovation and Deployment (OID) • Causal Analysis and Resolution (CAR) Continuous Process Improvement (2 PAs) • Organizational Process Performance (OPP) • Quantitative Project Management (QPM) Quantitative Management (2 PAs) • Requirements Development (RD) • Technical Solution (TS) • Product Integration (PI) • Verification (VER) • Validation (VAL) • Organizational Process Focus (OPF) • Organizational Process Definition (OPD) • Organization Training (OT) • Integrated Project Management (IPM) * • Risk Management (RSKM) • Decision Analysis and Resolution (DAR) • Organization Environment • for Integration (OEI) • Integrated Teaming (IT) Process Standardization (11 PAs) • Integrated Supplier • Management (ISM) Basic Project Management (7 PAs) • Requirements Management (REQM) • Project Planning (PP) • Project Monitoring and Control (PMC) • Supplier Agreement Management (SAM) • Measurement and Analysis (M&A) • Process and Product Quality Assurance (PPQA) • Configuration Management (CM) * Additional PA goals and activities added for IPPD Ad hoc, chaotic processes

  20. Software Process Variability • Software processes may vary radically from one organisation to another • Factors contributing to this variability include • Technical maturity • Disciplinary involvement • Organisational culture • Application domain • … • There is therefore no ‘ideal’ software engineering process[KotonyaSummerville98] Many Variety …and Evolution is inevitable

  21. Points to Ponder • What kind of software process are you using for doing your course project now? And why? • Have you ever reused any software components? If so, what kind of software process was used during the reuse? • When you carry out testing, what would be the criteria to say a line of program is an error?

More Related