Today, I occasionally visited the starting lecture of T-110.6000 Internet and Computing Forum P. The first lecture by Tuomas Syrjänen from Futurice was about rapid software development. There were several ideas that could (and should) be interesting to people interested in learning and improving software project management and software development practices. As far as I understood, both the lecture slides and the video recording of the lectures should eventually become available at their web site.
In any case, I'm aiming at participating the lectures from that course, and based on today's experience, can recommend this to others as well. Of course, some of the future topics are not that well connected to software project management, but are nonetheless interesting.
Tuesday, January 27, 2009
Estimating software projects
There are several aspects of software project that can be estimated. Most commonly the target of estimation in software projects is the effort needed to complete the project. Based on the effort estimate, a schedule can be built for the project. In many cases, in order to estimate the effort needed for the project, it's size must be estimated.
The estimation techniques can be roughly divided into two categories: heuristic estimation methods ("expert estimation") and algorithmic models ("formal methods"). Heuristic methods are based on knowledge and experience of one or more individuals, while algorithmic models are more formally specified, and are based on quantifiable input on the project. Commonly it is considered useful to combine several methods, in the best case both expert and algorithmic estimation is used. When combining the methods, the underlying assumptions should be evaluated and assessed when comparing the results from different methods. While many techniques can provide fairly accurate results, the largest benefit can be indeed exploited by understanding how these methods come up with their respective estimates.
I have written extra material for algorithmic models. Hopefully this material, and its references, will help you to understand how function point analysis and constructive cost model should be applied to software project estimation. Also, the Wikipedia article on software development effort estimation is one starting point for more information. For recent research on software project estimation, I recommend to browse through the research articles by professor Magne Jørgensen from Simula Research Laboratory, Norway.
The estimation techniques can be roughly divided into two categories: heuristic estimation methods ("expert estimation") and algorithmic models ("formal methods"). Heuristic methods are based on knowledge and experience of one or more individuals, while algorithmic models are more formally specified, and are based on quantifiable input on the project. Commonly it is considered useful to combine several methods, in the best case both expert and algorithmic estimation is used. When combining the methods, the underlying assumptions should be evaluated and assessed when comparing the results from different methods. While many techniques can provide fairly accurate results, the largest benefit can be indeed exploited by understanding how these methods come up with their respective estimates.
I have written extra material for algorithmic models. Hopefully this material, and its references, will help you to understand how function point analysis and constructive cost model should be applied to software project estimation. Also, the Wikipedia article on software development effort estimation is one starting point for more information. For recent research on software project estimation, I recommend to browse through the research articles by professor Magne Jørgensen from Simula Research Laboratory, Norway.
Monday, January 26, 2009
Lectures in MP3 format
The lectures of this course in mp3 format are now available at the Noppa page of this course. The files are totally unedited and unfiltered, so you may expect few minutes of delays in the beginning. Sorry for any inconvenience - I try to minimize my own work and reduce latency in publishing the files.
The links to mp3 are in the header, and stored on another server, as Noppa has a maximum limit of 50M per file :) Let me know if there are any problems.
Any comments or improvement ideas on mp3s are welcome.
The links to mp3 are in the header, and stored on another server, as Noppa has a maximum limit of 50M per file :) Let me know if there are any problems.
Any comments or improvement ideas on mp3s are welcome.
Choosing process model
The selection of process model for a software project is a tedious task. There are many factors affecting the optimal choice of software process framework for a process. When selecting a process model, one must carefully assess the context of the project:
Also, in reality, there are several constraints in selecting the process model, often leading to suboptimal process choice for a given project. Especially in larger companies, there are often only one (or at most, a couple) process framework, that must be followed in all endeavours of the organization. If you are planning to use e.g. agile practices, and the organization is not familiar with the principles, are you able to get management buy-in for your ideas?
While the evolution of software process models have historically moved from document-driven (or plan-driven), waterfallish models towards more flexible agile methods, there still is no silver bullet process framework. New process models often aim to fix the problems of earlier paradigms and models, but as with most improvements, this often leads to other challenges. There is still relatively few research on using agile practices in producing large, complex software systems. In general, agile practices shed little (if any) light into issues related to software maintenance, or software as a service. Document-driven methods are strong with requirements engineering, while e.g. Scrum hides the issue behind the concept of Product Owner, and backlog items. On the other hand, agile practices highlight the importance of team motivation and (informal) communication; an aspect document-driven models often neglect.
The selection of process model affects management of software project in several ways. The pace and contents of interaction with the customer / end-user are highly affected by the software process model in use. The roles used by software development organization should be aligned with the software process model. Even the structure of the product to be developed must match with the chosen organization and practices of the software project team.
When considering issues with software processes, it is very important to keep critical attitude, and ask questions. There still are no simple answers to difficult questions.
For those more interested in software processes, TKK provides an excellent course on the topic.
- Is the project small or large in terms of effort, schedule, or business value?
- How much risk is involved in the project? What is the relative importance of this project in comparison to other projects, and the overall activities of the company?
- How much changes can be anticipated? Is it possible to come up with stable, definitive requirements for the project up-front, or do we have to work on something, and rely on customer feedback for next steps?
- How many people are involved in the project, both directly and indirectly? How competent are they? Are they familiar with the process we are planning to use?
- Is the whole team located at same room, floor, building? How are we going to communicate during the project?
Also, in reality, there are several constraints in selecting the process model, often leading to suboptimal process choice for a given project. Especially in larger companies, there are often only one (or at most, a couple) process framework, that must be followed in all endeavours of the organization. If you are planning to use e.g. agile practices, and the organization is not familiar with the principles, are you able to get management buy-in for your ideas?
While the evolution of software process models have historically moved from document-driven (or plan-driven), waterfallish models towards more flexible agile methods, there still is no silver bullet process framework. New process models often aim to fix the problems of earlier paradigms and models, but as with most improvements, this often leads to other challenges. There is still relatively few research on using agile practices in producing large, complex software systems. In general, agile practices shed little (if any) light into issues related to software maintenance, or software as a service. Document-driven methods are strong with requirements engineering, while e.g. Scrum hides the issue behind the concept of Product Owner, and backlog items. On the other hand, agile practices highlight the importance of team motivation and (informal) communication; an aspect document-driven models often neglect.
The selection of process model affects management of software project in several ways. The pace and contents of interaction with the customer / end-user are highly affected by the software process model in use. The roles used by software development organization should be aligned with the software process model. Even the structure of the product to be developed must match with the chosen organization and practices of the software project team.
When considering issues with software processes, it is very important to keep critical attitude, and ask questions. There still are no simple answers to difficult questions.
For those more interested in software processes, TKK provides an excellent course on the topic.
Tuesday, January 20, 2009
Exercises
Hello all,
The exercises for the course have been published, please see assignments page in course web page for more details.
Last two exercises are made in groups, so you can start forming your team now. The course newsgroup may help you in this endeavour.
br,
Tuomas
The exercises for the course have been published, please see assignments page in course web page for more details.
Last two exercises are made in groups, so you can start forming your team now. The course newsgroup may help you in this endeavour.
br,
Tuomas
Welcome to the Course, Spring 2009
Dear student of course T-76.5612 Software Project Management,
Welcome to the course, and to the course blog!
As the topic suggests, this course is about software projects, and how to manage them. We will be discussing several aspects of software project management, especially focusing on following issues:
In addition to lectures given by the course personnel, we will have guest lectures from industry with varying topics. As software project management is an art that cannot be fully taught or studied from theoretical perspective, I encourage you to explore all possibilities to exploit their insights and experience on software project management - you may learn how to do so with the lectures given by course personnel! Thus, I encourage you to be active during the lectures and throughout the course.
In addition to intellectual debates, it is worth to remember, that we are all human, and mistakes can and will occur; in any case you don't understand what is being said, or course arrangements just doesn't make sense to you, please ask!
The authoritative source of information for the course assignments is the course page in Noppa portal. Please make sure you have subscribed to course news, either by email or RSS. More specific instructions how to do so are available at the Noppa portal.
This blog will serve as auxillary communication channel during the course. Passing the course is completely possible without ever reading this blog, but more detailed insights and discussion about lecture topics and other interesting issues will be posted on this blog. As a rule, we aim at posting to blog after each lecture, to summarize the points from the lecture, as well as raise some important issues. We will also answer to any questions, in case any is raised (either in the lecture, or afterwards).
That said, I'd like to have active participation and discussion on the blog, for two reasons. Firstly, I hope interacting with you on this blog over the topics of the course will help both you and me to understand the discussed issues more deeply. Secondly, the blog can serve as very informal, yet effective feedback channel, so in case you have any suggestions or worries about the course format, exercises or software project management in general, please post a comment.
In this course, we will embrace activity. Therefore extra points will be awarded based on activity, both during lectures and in the blog.
Welcome to the course, and to the course blog!
As the topic suggests, this course is about software projects, and how to manage them. We will be discussing several aspects of software project management, especially focusing on following issues:
- What is a software project?
- Constraints, goals and types of a software project
- Software processes in software project management
- Software project estimation
- Budgeting, scheduling and monitoring software project
- Software quality and risk management
- Leadership and management in software projects
- Distributed software development
In addition to lectures given by the course personnel, we will have guest lectures from industry with varying topics. As software project management is an art that cannot be fully taught or studied from theoretical perspective, I encourage you to explore all possibilities to exploit their insights and experience on software project management - you may learn how to do so with the lectures given by course personnel! Thus, I encourage you to be active during the lectures and throughout the course.
In addition to intellectual debates, it is worth to remember, that we are all human, and mistakes can and will occur; in any case you don't understand what is being said, or course arrangements just doesn't make sense to you, please ask!
The authoritative source of information for the course assignments is the course page in Noppa portal. Please make sure you have subscribed to course news, either by email or RSS. More specific instructions how to do so are available at the Noppa portal.
This blog will serve as auxillary communication channel during the course. Passing the course is completely possible without ever reading this blog, but more detailed insights and discussion about lecture topics and other interesting issues will be posted on this blog. As a rule, we aim at posting to blog after each lecture, to summarize the points from the lecture, as well as raise some important issues. We will also answer to any questions, in case any is raised (either in the lecture, or afterwards).
That said, I'd like to have active participation and discussion on the blog, for two reasons. Firstly, I hope interacting with you on this blog over the topics of the course will help both you and me to understand the discussed issues more deeply. Secondly, the blog can serve as very informal, yet effective feedback channel, so in case you have any suggestions or worries about the course format, exercises or software project management in general, please post a comment.
In this course, we will embrace activity. Therefore extra points will be awarded based on activity, both during lectures and in the blog.
Subscribe to:
Posts (Atom)