[2015/2016] Software development process
6 likes2,187 views
The document outlines various software development process models, highlighting the importance of structured methodologies like waterfall, spiral, and agile for improving predictability and quality. It discusses the significance of requirements engineering, software architecture, and continuous testing in ensuring successful project outcomes, along with a focus on iterative development and customer collaboration in agile methodologies. Additionally, it explores the open-source development process, emphasizing community involvement and the critical examination of various development models.
![[2015/2016] Software development process](https://image.slidesharecdn.com/03devprocess-151201102814-lva1-app6892/85/2015-2016-Software-development-process-2-320.jpg)
![Suggested readings
1. Alfonso Fuggetta and Elisabetta Di Nitto. 2014. Software process.
In Proceedings of the on Future of Software Engineering (FOSE
2014). ACM, New York, NY, USA, 1-12.
2. Striebeck, M., "Ssh! We are adding a process... [agile practices],"
Agile Conference, 2006 , vol., no., pp.9 pp.,193, 23-28 July 2006
3. Nicolò Paternoster, Carmine Giardino, Michael Unterkalmsteiner,
Tony Gorschek, Pekka Abrahamsson, Software development in
startup companies: A systematic mapping study, Information and
Software Technology, Volume 56, Issue 10, October 2014, Pages
1200-1218,ISSN 0950-5849](https://image.slidesharecdn.com/03devprocess-151201102814-lva1-app6892/85/2015-2016-Software-development-process-82-320.jpg)
[2015/2016] Software development process
- 3. Roadmap Introduction Classical software development processes Agile Open-source software development
- 4. Discussion If you need to develop a system with 10M LOCS, • How many people do you need? • How much time? • How do they synchronize? • How do you know that you are performing well?
- 5. Software development process Developing software without a defined process is chaotic and inefficient Following a defined process makes software development more orderly, predictable and repeatable . . . . . . Slide by Cesar Augusto Nogueira, IBM
- 6. Life cycle From inception of an idea for a product through: • requirements gathering and analysis • architecture design and specification • coding and testing • delivery and deployment • maintenance and evolution • retirement
- 7. Software process model Attempt to organize the software life cycle by defining – activities involved in software production – order of activities and their relationships Goals of a software process – standardization, predictability, productivity, high product quality, ability to plan time and budget requirements
- 8. Code & Fix: the naïve process model • Write code • Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features • Source of difficulties and deficiencies – impossible to predict – impossible to manage
- 9. Models are needed Symptoms of inadequacy: the software crisis – scheduled time and cost exceeded – user expectations not met – poor quality The size and economic value of software applications required appropriate “process models” VS
- 10. Process model goals (B. Boehm 1988) “determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions: What shall we do next? How long shall we continue to do it?”
- 11. Process as a "black box" Product Process Informal Requirements
- 12. Problems The assumption is that requirements can be fully understood prior to development Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately this assumption almost never holds
- 13. Process as a "white box" Product Process Informal Requirements feedback
- 14. Advantages Reduce risks by improving visibility Allow project changes as the project progresses – based on feedback from the customer Why a project may change?
- 15. The main activities They must be performed independently of the model The model simply affects the flow among activities Requirements engineering Feasibility study Architecture and detailed design Implementation and testing Delivery, deployment, and maintenance
- 16. Example from an EU project ConstRaint and Application driven Framework for Tailoring Embedded Real-time Systems http://www.crafters-project.org
- 17. Why CRAFTERS? PROBLEMS poorly interoperable proprietary technologies à poor time to market + high costs SOLUTION Seamless connectivity and middleware – by realizing a common middleware layer that is designed to support newwireless communication standards – portable across different platforms Ability to develop powerful design time solutions with notably shorter cycles – thanks to the unique tool chain delivered with reference middleware and hardware
- 18. Feasibility study Why a new project? • cost/benefits tradeoffs • buy vs make – Requires to perform preliminary requirements analysis – Produces a feasibility study document 1. Definition of the problem 2. Alternative solutions and their expected benefits 3. Required resources, costs, and delivery dates in each proposed alternative solution
- 19. CRAFTERS feasibility study Project proposal submitted to the ARTEMIS Call 2011 Project
- 20. Requirements engineering Involves – eliciting – understanding – analyzing – specifying Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models User and system requirements Requirements document Focus on – what qualities are needed, – NOT on how to achieve them
- 21. The requirements specification document (1) Provides a specification for the interface between the application and the external world – defines the qualities to be met Has its own qualities – understandable, precise, complete, consistent,unambiguous, easily modifiable
- 22. The requirements specification document (2) Must be analyzed and confirmed by the stakeholders – may even include version 0 of user manual As any large document, it must be modular – "vertical" modularity • the usual decomposition, which may be hierarchical – "horizontal"modularity • different viewpoints Defines both functional and non functional requirements
- 23. Requirements in CRAFTERS (1) Set of relevant use cases first
- 24. Requirements in CRAFTERS (2) Then, requirements collection and formulation
- 25. Software architecture and detailed design activity Usually follows a company standard, which may include a standard notation, such as UML The result of this activity is: – the software architecture description – a design specification document We will have a dedicated lecture on this activity
- 26. General model of the design process Interface design Component design System architecture Database specification Interface specification Requirements specification Architectural design Component specification Platform information Data description Design inputs Design activities Design outputs Database design
- 27. Architecture in CRAFTERS (1)
- 28. Design in CRAFTERS (2)
- 29. Design in CRAFTERS (3)
- 30. Design in CRAFTERS (4)
- 31. Verification and validation Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the customer Involves: checking and review processes AND system testing System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system Testing is the most commonly used V & V activity
- 32. Coding and module testing activity Company wide standards often followed for coding style We will have a dedicated lecture on this activity System testing Component testing Acceptance testing
- 33. Testing stages Development or component testing – Individual components are tested independently – Components may be functions or objects or coherent groupings of these entities System testing – Testing of the system as a whole. Testing of emergent properties is particularly important Acceptance testing – Testing with customer data to check that the system meets the customer’s needs
- 34. Coding and testing in CRAFTERS Prototype implementation based on 3 different HW platforms For example:
- 35. Software evolution Software is inherently flexible and can change Although there has been a demarcation between development and evolution (maintenance), this is increasingly irrelevant as fewer and fewer systems are completely new Assess existing systems Define system requirements Propose system changes Modify systems New system Existing systems
- 36. What you need to remember Requirements engineering create the software specification Design and implementation requirements à executable software Software verification and validation to check that the system conforms to its specification and that it meets the real needs of the users of the system Software evolution new requirements à the software must evolve to remain useful
- 37. Roadmap Introduction Classical software development process Agile Open-source software development
- 38. Classical software process models* Waterfall model Spiral model Microsoft’s Synch-and-Stabilize * these are the most known process models, it is not a complete list Quality-oriented model
- 39. Waterfall model Exist in many variants, all sharing sequential flow style It is document-driven Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
- 40. Waterfall model Organizations adopting them standardize the outputs of the various phases (deliverables) May also prescribe methods to follow in each phase – organization of methods in frameworks often called methodology Example: Military Standard (MIL-STD-2167)
- 41. Alternative: the V model Emphasis on V&V activities Acceptance tests written with requirements Unit/integration tests written during design
- 42. Critical evaluation of the waterfall model + sw process subject to discipline, planning, and management à standard-oriented + postpone implementation to after understanding objectives + good documentation – difficult to gather all requirements once and for all – users may not knowwhat they want – linear, rigid, monolithic – no feedback from the customer – no parallelism, all phases are blocking – a single delivery date (at the end!)
- 43. Spiral model Risks are explicitly assessed and resolved Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration test Acceptance testService Develop, verify next-level product Evaluate alternatives, identify, resolve risks Determine objectives, alternatives and constraints Plan next phase Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW
- 44. Spiral model sectors Objective setting – Specific objectives for the phase are identified Risk assessment and reduction – Risks are assessed and activities put in place to reduce the key risks Development and validation – A development model for the system is chosen which can be any of the generic models + implementation & validation Planning – postmortem of previous loop, planification of next loop
- 45. Critical evaluation of the spiral model + a good fit if requirements are not stable + flexible, but still with a plan + risks are assessed clearly + customer involvement + good documentation – difficult to assess risks – difficult to assess objectives and constraints
- 46. Quality-oriented model Mathematical formalism to express requirements Model checking to prove correctness + automatic transformations to code = preserve correctness
- 47. Critical evaluation of the quality- oriented model + a good fit for to safety/security critical parts + if requirements are correct, risks are totally controlled + verification is implicit à potentially, less testing needed – math languages require specific skills, rarely available – some parts (ex user interface) cannot be specified formally – validation of requirements still an issue – customer does not understand math language – specifier may misunderstand requirements
- 48. Microsoft’s Synch-and-Stabilize CONTEXT Time to market essential Requirements can’t be fixed early on Complex products (Mlocs) with several interacting components Design hard to devise and freeze early on Michael A. Cusumano and RichardW. Selby. 1997. How Microsoft builds software. Commun. ACM 40, 6 (June 1997), 53-61. DOI=10.1145/255656.255698
- 49. Microsoft’s S-and-S phases Planning – vision of the product – Specification – Teamwork schedule Development – team composed of 2 groups • developers and testers (continuous testing) Stabilization – internal testing – externaltesting – release
- 50. Planning phase Vision Statement - Product Managers – Define goals for the newproduct – Priority-order user activities that need to be supported by product features Deliverables: – Specification document – Schedule and “feature team” formation • 1 program manager • 3-8 developers • 3-8 testers (1:1 ratio with developers)
- 51. Development phase Plan 3-4 sequential subprojects (lasting 2-4 months each) Subprojects -- design, code, debug – starting with most critical features and shared components – feature set may change by 30% or more – each developer is committed only to his assigned tasks
- 52. Subproject development Feature teams go through the complete cycle of development, feature integration, testing and fixing problems Testers are paired with developers Feature teams synchronize work by building the product, finding and fixing errors on a daily and weekly basis Code that breaks a build must be fixed immediately At the end of a subproject, the product is stabilized
- 53. Stabilization Internal testing of complete product External testing – beta sites – ISVs (Independent SW vendors) – OEMs (Original Equipment Manufacturers) – end users Release preparation
- 54. Critical evaluation of Microsoft’s method + Responsiveness to marketplace: they always have a release to ship + allows to ship preliminary versions early + allows to add features in subsequent releases + continuous customer feedback + breaks down large projects into manageable pieces (with priorities) – poor focus on product architecture – no rigorous approach to design & code reviews – e.g., Video on demand components have real-time constraints that require precise mathematical models – no focus on defect prevention
- 55. Roadmap Introduction Classical software development process Agile Open-source software development
- 56. Agile
- 57. Waterfall vs agile: poor visibility
- 58. Waterfall vs agile: poor quality
- 59. Waterfall vs agile: too risky
- 60. Waterfall vs agile: can’t handle change
- 62. Agile manifesto We are uncoveringbetterways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software overcomprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://www.agilemanifesto.org
- 63. How does it work in practice? You make a list You start executing You estimate You update the plan “@run-time” You set priorities
- 64. Agile iterations
- 65. Agile principles (extract) Agile methods are iterative development processes with: • frequent releases of the product • continuous interaction between dev. team and customer • reduce product documentation • continuous and systematic assessment of produced value and risks
- 67. Technical tools: unit tests Snippet of test code for exercising some functionality of the product à codified requirements We will have a dedicated core course on testing
- 68. Technical tools: test-driven development Write tests first Refactoring is less risky now
- 69. Technical tools: continuous integration Merging all the developers’ working copies many times a day à it allows to make sure that all the code integrates, all the unit tests pass, and a warning if anything goes wrong image from http://newmedialabs.com/
- 73. An implementation: SCRUM Burndown chart = how much work is left Scope changes • The engineering team missed features in the UI mockups when we created the release backlog • Integrations into other AdWords features were overlooked • The rate of change in AdWords APIs is very high.
- 74. Critical evaluation of the agile method + Acceptance of change à less risky + Frequent and short iterations + Emphasis on working code + Associating a test with every piece of functionality + tests are a key resource within the project + Continuous integration (and delivery) + Planned – Tests as a replacement for specifications – feature-based development & ignorance of dependencies – no quality plan – dismissal of a priori architecture work – actually, dismissal of everythingwhich is non-shippable
- 75. Roadmap Introduction Classical software development process Agile Open-source software development
- 76. Open source development process As applied in successful projects: – Apache – Mozilla – … Tools • GitHub (config management system) • Mailing lists • Bugzilla (Bug tracking) Products • Source code, test suites • all related information, like mails, bugs, comments, etc.
- 77. It doesn't just mean access to the source code 1. Free redistribution 2. Source code 3. Derived works 4. Integrity of the author's source code 5. No discrimination against persons or groups 6. No discrimination against fields of endeavor 7. Distribution of license 8. License must not be specific to a product 9. License must not restrict other software 10. License must be technology-neutral www.opensource.org/docs/definition.php
- 78. Roles • Core team (2-8 people) – Architecture,requirements, integration/build, release • Patch developers (10-100) – Patch (evolutive + corrective) • Bug providers (100 – 1000+) – Signal bugs, may perform pull requests, etc. • Others (thousands) – Download and use
- 79. Overview of the process The process is “public” • everyone can participate Releases are checked by a revision board that tests proposed code from the community Very frequent builds Often quite frequent releases • once a month
- 80. Critical evaluation of the open- source model + simple and effective tools for bug/change tracking + continuous delivery + resiliency with respect to team members (openness) + “no maintainance” – limited documentation (not always) – no project plan – no quality plan
- 81. What this lecture means to you? No “silver bullet” Linear processes: planned, not flexible Iterative processes: planned, flexible, less risky Quality-oriented processes: planned, not flexible, measured Agile: not planned, test-driven
- 82. Suggested readings 1. Alfonso Fuggetta and Elisabetta Di Nitto. 2014. Software process. In Proceedings of the on Future of Software Engineering (FOSE 2014). ACM, New York, NY, USA, 1-12. 2. Striebeck, M., "Ssh! We are adding a process... [agile practices]," Agile Conference, 2006 , vol., no., pp.9 pp.,193, 23-28 July 2006 3. Nicolò Paternoster, Carmine Giardino, Michael Unterkalmsteiner, Tony Gorschek, Pekka Abrahamsson, Software development in startup companies: A systematic mapping study, Information and Software Technology, Volume 56, Issue 10, October 2014, Pages 1200-1218,ISSN 0950-5849
- 84. Contact Ivano Malavolta | Post-doc researcher Gran Sasso Science Institute iivanoo ivano.malavolta@gssi.infn.it www.ivanomalavolta.com