1. 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

2. 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

3. 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

4. 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

5. 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

6. 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.

7. 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

8. 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