Use cases: actors vs. stakeholders

Use cases are one of the most important parts of the Software Engineering. They are a sequence of steps or events which describe the interactions between an actor and the system for a certain functionality. Use cases are usually represented as a diagram that includes two components which sometimes may cause confusion: actors and stakeholders. We will try to briefly set their definitions and features, as well as give some examples:

Actors: They are external entities that interact with a system in same way, in other words, "anything" with some behavior that acts on the system. Actors represents a role which an user can play in our project, and they must be able to make decisions, however, they do not need to be humans (very important!). Their behavior may be considered as "non-deterministic" (they are different from other objects).

Examples of actors: end users, user roles, persons, companies, organizations, networks, computers that the system needs (hardware), databases, applications (software), etc.

Stakeholders: They are entities that care of the project in some way. Other definition of stakeholder may be "an individual who is materially affected by the outcome of the project" (proposed by RUP, Rational Unified Process). Anyway, we need to clear that the fact of being a stakeholder does not necessarily imply to get a benefice from the project. Besides, we can say that actors are always stakeholders, but this relation is not bidirectional (not always a stakeholder is an actor). The main difference between stakeholders and actors is that stakeholders may not appear on use cases.

Examples of stakeholders: end users of the system, investors, suppliers, customers, vendors, corporations, companies, even developers of their own project.

Carpooling 505 proposal timeline

The project Carpooling 505 will not be developed in any complex or dynamic environment. For this reason, I decided to discard agile methodologies such as Scrum. Therefore, the chosen methodology for this project would be a classic sequential waterfall model. Besides, this project seems quite rigid, and I do not expect many changes from the original idea, these are two examples of points to take into account when you select a waterfall based methodology.

Notice that a maintenance phase should be included as part of the waterfall model, but we only have 12 weeks to be the project launched. For this reason, we assume the maintenance as a separate process after the website will be working properly.

The following two figures show a 12 week proposal timeline for the Carpooling 505 project:

Gantt diagram for Carpooling 505 (click to enlarge)

Task workflow network based on the Gantt diagram (click to enlarge)

Timeline description:

Group meetings: half an hour once a week. The main goal of these meetings is to keep track of the work done so far, and plan the next task for each member of the group. Suggestions and questions are always welcome on the group meetings.

Overview and planification: presentation, components of the team, first steps, ideas, suggestions, brainstorming, etc. 

Learn technologies: let's suppose that not all the members of the group know the technologies which will be used (Joomla!, PHP, MySQL, etc.)

Requirements: It includes elicitation, analysis, specification and management. The outcome will be a Software Requirements Specification.

System modeling (backend): designing of the application that will match the transportation requirements provided by the users. Joomla! database connections.

System modeling (frontend): Full website design.

System implementation (backend): development and implementation of the application that will match the transportation requirements.

System implementation (frontend): Website implementation using Joomla! CMS.

System integration: Embed backend application into the CMS (frontend). Web hosting and domain name.

Testing: Design a test plan. Depending on the requirements, the team will plan test such as unit test, quality test, integration test, load & stress test, etc.

Deployment and delivery: Launch website (domain name and hosting ready). 

Marketing: promotion on Media, advertising, etc. (if required)

Project start/end: "milestones"

Project proposal: Carpooling 505

Carpooling 505 is a project to share vehicles for trips and journeys, with the major goal of avoiding cars occupied by only one. In general, urban planning in the US makes using a car and other kinds of vehicles a must. Nowadays, there exists a carpooling service endorsed by the City of Albuquerque that is provided by a third-party website, but it is focused only on local trips, and additionally, it is not well promoted, causing a lack of usage.

Our team will design a website using Joomla!, a well-known Open Source Content Management System, that allows users to either offer their vehicles to use with more people, or find people who are willing to share their vehicle for going to work, leisure travels, etc. Social media connections will also be an important part of the project to boost it up, getting as much users as possible.

Albuquerque inhabitants with travelling needs within New Mexico or out of the state could take advantage of this website. Carpooling 505 is an easy way to save money and time, as well as contribute to reducing traffic jams and pollution levels. As this project will be focused not only on workers (which is usually the main target), but also on students or everyone who needs a ride, it will also bring the opportunity to meet new people and create a community of users.

At the beginning, this project will require low investment since we will use Open Source software to build it. Hosting and domain expenses may be paid by Albuquerque government, because Carpooling 505 will be a public service which will contribute to improve citizen’s welfare. Regarding the maintenance of the project, an Open Source user community may support it, extending its features on demand and improving its usability based on users feedback posted either on social networks or a ‘wish list’ phorum.

Be part of carpooling 505 and start saving money and time.

What does Software Engineering mean? (II)

In the last lecture, we had an interesting discussion about the definition of Software Engineering. Most of the students made their suggestions, and we shared different points of view. Finally, professor Dave Ackley wrote the following explanatory graph:

This chart defines four dimensions: "see", "judge", "prediction" and "action". On one hand, science  (green) usually gathers "see" and "prediction". We can say that science does not imply knowing "how to do it". In contrast, engineering discipline (blue) is commonly based on "actions" and "predictions". Therefore, "how to do it" is what really matters.

Software engineering is exactly the union between both science and engineering (green + blue). We need to put both together in order to get the whole meaning associated to this term, which involves other features such as being creative.

What does Software Engineering mean?

My name is Fernando Serrano. I am a Computer Systems Engineering graduate from Universidad de Alcalá (Madrid, Spain), and  I also have a Master's degree in Information Technology Project Management in the same university.

Since August 2013, I am an exchange student of BSc Computer Science at The University of New Mexico. My main interests are all the things related to Open Source software, especially those which are focused on web development. On the other hand, I am also interested in both project management (as part of my postgraduate education), and social media networking.

The aim of this blog is to provide information about different aspects of the world of Software Engineering, and particularly the ones which are related to my interests. As Software Engineering itself includes a broad branch of subjects, I will try to write about as much topics as possible, not only about the history an evolution of this discipline, but also regarding current issues, new approaches, as well as applications, models, case studies, etc.

The first question that arises when we talk about Software Engineering is, what does it really mean? We can easily find several definitions of this concept, for example, at Wikipedia website we can read a definition wrote by the Institute of Electrical and Electronics Engineers in the IEEE Standard Glossary of Software Engineering Terminology:

"The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software"

Other approaches proposed by several authors agree with this other definition (in fact, this is one of the most common definitions of Software Engineering):

"The study and application of engineering to the design, development, and maintenance of software"

Anyway, it is clear that Software Engineering is a discipline concerned with developing applications, which covers technical aspects of building software and other topics such as management issues, programming teams, even things that we may not directly associate with Software Engineering, for example scheduling or budgeting.

The definition of software engineering is not too old. It was firstly given in 1968 "as a response to the desolate state of the art of developing quality software on time and within budget" (Bruegge B. and Dutoit A. H.  Object-Oriented Software Engineering Using UML, Patterns, and Java. Prentice Hall, 1994). Bernd Bruegge, Allen H. Dutoit also proposed a definition of Software Engineering, but they used a schematic approach to explain the meaning of this term:

• Software engineering is a modeling activity.
• Software engineering is a problem-solving activity.
• Software engineering is a knowledge acquisition activity
• Software engineering is a rationale-driven activity.

Summarizing, we have seen there are a lot of definitions of Software Engineering which have arose in the last forty years, and taking into account the fast evolution of this discipline, this definition may change in the following years.