Yes, we need hundreds of methodologies!!! It is only in this way we get to know what we do and how we can do “this what” better!!!! Yes, we need many methodologies. How else do we know what we do and what we should do? How else can we communicate? How else can we evaluate whether the things we do are good or not? Let me provide you with some examples. Mira Kajko-Mattsson Department of Computer and Systems Sciences Stockholm University and Royal Institute of Technology Sweden 1 1

Development, evolution and maintenance in ancient times 30/11/2018 Development, evolution and maintenance in ancient times Programmer Manager The Topic preview slide prepares learners for the topic. It provides a concise introduction and overview. Use the subtitle to further explain the title or to introduce the bullet list. Or, delete the subtitle. Summarize the main points of your topic using the bullet list. Use voice narration to explain each bullet item and to elaborate upon it. Replace the graphic placeholder with a relevant graphic to lock in the concept. The graphic could show an example of the concept, a diagram of the concept, or a formula for a relationship. If your topic is very simple, you may want to omit this slide. If you are using a strategy of discovery learning, you may want to move this slide to the end of the topic where it serves as a summary. No process model (write code, fix code) No documentation The programmer was the craftsman? The work product of ”these craftsmen” was not always of good quality

With time, however…… Programmer Manager 30/11/2018 In 1968, Bauer coined the term Software Engineering which has been in widespread use since. during the NATO Software Engineering Conference in 1968

We should act like engineers, like software engineers 30/11/2018 With time, however…… Large amount of functionality is never delivered The product is late, overbudgeted, defective, never delivered, useless, of low quality, etc. Lack of product and process knowledge The product is difficult to change Only as subset of delivered functionality is frequently used Engineers are overworked The product quality is too low Software cost exceed hw cost We should act like engineers, like software engineers Manager Manager Manager In 1968, Bauer coined the term Software Engineering which has been in widespread use since. during the NATO Software Engineering Conference in 1968

Attempts to improve development Content Starter Set Attempts to improve development V-model Spiral model The Topic preview slide prepares learners for the topic. It provides a concise introduction and overview. Use the subtitle to further explain the title or to introduce the bullet list. Or, delete the subtitle. Summarize the main points of your topic using the bullet list. Use voice narration to explain each bullet item and to elaborate upon it. Replace the graphic placeholder with a relevant graphic to lock in the concept. The graphic could show an example of the concept, a diagram of the concept, or a formula for a relationship. If your topic is very simple, you may want to omit this slide. If you are using a strategy of discovery learning, you may want to move this slide to the end of the topic where it serves as a summary. Incremental development OOAD CBD Agile development Daily Build Formal methods MDA 5

The phased development has a number of advantages: Customers do not have to wait until the entire system is delivered. The first increment usually satisfies their most critical requirements so that the software can be immediately used. Customers can use the early increments as form of prototype and gain experience which helps them identify requirements for later system increments. Training can already begin on an early release, even if some functions are missing. The training process allows developers to observe how certain functions are executed, suggesting enhancements for later releases. There is a lower risk of overall project failures. Although problems may be encountered in some increments, it is likely that some will be successfully delivered to the customer. Frequent releases allow developers to fix unanticipated problems quickly, as they are reported from customers. As the highest priority service are delivered first and later increments are integrated with them, it is inevitable that the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most important parts of the system. The development team can focus on different areas of expertise with different releases. For instance, one release can change the system from a command-driven one to a point-and-click interface, using the expertise of user-interface specialists; another release can focus on improving system performance. Markets can be created early for functionality that has never before been offered.

Software Engineering contra Good Enough Software Development 30/11/2018 Software Engineering contra Good Enough Software Development I wouldn’t like to fly a plane having good enough software In 1968, Bauer coined the term Software Engineering which has been in widespread use since. during the NATO Software Engineering Conference in 1968 We are now challenging the Software Engineering term . 7

We need process models because they lay out what needs to be done. Improve communication within the organization enable repetition of success ensure that lessons learned are paid heed to improve schedule and budget predictability cycle time productivity quality (as measured by defects) customer satisfaction employee morale increase return on investment decrease cost of quality ...... The waterfall model can be very useful in helping developers lay out what they need to do. Its simplicity makes it easy to explain to customers who are not familiar with software development: It makes explicit which intermediate products are necessary in order to begin the next stage. Many other, more complex models are really just embellishments of the waterfall, incorporating feedback loops and extra activities. It is a simple management model. It is easy to manage. And if the requirements are well understood from the very beginning, it should lead to robust systems that are amenable to change. 8