jump to navigation

Five Trends that Every Software Engineer Needs to Know December 16, 2011

Posted by davevankampen in Software Engineering.

Software Product Lines
Software product lines probably bear the most potential for interesting legal issues coming up of all the topics discussed. Software product lines are all about developing a consistent look, feel, purpose, mission, etc. for a company or organization’s software offerings.
A good example of a software product line is the Apple Company’s products. They have a very consistent look and feel about them. They have a scheduled deployment method, where it grows and evolves as a group.
The software engineering fundamental that applies to software product lines is that of project management. Software product lines are about managing a product across multiple products. This is the only way you will be able to even get close to having an SPL. I listed this in my fundamentals of software engineering.
In addition, Deloitte mentions the importance of user engagement as a disruptive method within software engineering. Users, in general, prefer consistency. Once again, the brand consistency of the Apple and Mac lines deserves reference at this point. Most users do not really like change. They like improvement, and evolution, but not change. You can very effectively manage your user’s experience and engagement level with good software product line management.

DevOps (Emerging Process model and ITIL)
DevOps stands for “Development and operations.” It signifies the merging of the two business practices. Traditionally, these departments operate in a very “siloed” fashion. However, the DevOps movement is a push to integrate. It ensures that the software development people keep in mind the needs of the operations and deployment group. That is, it makes the development group a little more customer aware, while giving a voice to the operations people, and a clearer and easier channel for them to communicate through.
The DevOps topic really applies to almost every software engineering fundamental. There is really nothing about it that does not scream “best practice.” Specifically, however, I would say that it applies most to Software Integration, Maintainability, and quality. Like software product lines (discussed later), its about making the same job easier. It is about bridging the gap during the integration and deployment stage. So, I would say this definitely applies to the topics discussed this semester.

Feature Oriented Programming
One important feature of good software engineering that FOP and FOSD (feature oriented software development) meets is that of modularity and maintainability (an important element from my list of what defines good software engineering). FOP is all about analyzing the domain that the software product will be deployed in, and making the software modular enough to be used in multiple projects. Feature oriented programming has a lot of similarities with Object Oriented programming (OOP) which is also a very big and smart push in software engineering these days.
I think the aspect of software engineering that applies most to FOP is software maintainability. Designing for features is something that is (or at least could be) common to every single project out there today that is built using software. It just takes a new way of looking at it. Therefore, if you start looking at it that way, those features or aspects can be ported from one project to another in a much more human-understandable way. In addition, a product design in a feature-based way will be much easier to hand off or pass from one developer to another, since feature-based thinking comes a lot more naturally to people.

Software Ecosystems
A software ecosystem is a very interesting emerging topic in software engineering. Software ecosystems are all about integrating existing elements when you begin a project, and not having to develop everything from the ground up every time. A big feature of software ecosystems (as it was with software product lines) is the intra-organizational aspect of things.
Software ecosystems are all about taking software product lines one step further. It is about integrating software systems across divisions, departments, organizations, and even corporations. It takes different (working) and successful elements from their projects and makes them interact and interface in new ways to create bigger and better systems.
That being said, I feel that Project Management is the most important element when it comes to creating a solid software ecosystem. And not just project management, but business management at every level. It will take every party’s buy in for something like this to work, as it is a serious financial as well as legal investment. It is possible that a software ecosystem can be developed within a single organization, but they will work best when competing parties decide to work together on at least this aspect of it, and move forward from there.

End User Programming and End User Software Engineering
End user programming, of all the topics covered below, I feel has the potential for the greatest impact on the practice of software engineering. At first blush, it seems like it an example of the programmer being lazy. However, developing a program that uses EUP creatively, effectively, and without introducing many possible bugs is very difficult. When though about in relation to the topics in Deloitte’s paper, and those I mentioned in the initial “What is Software Engineering?” discussion post, I think the topics of safety, quality, and testing come to mind first and foremost.
These are all centralized on the topic of quality. Allowing the end user to do some programming means your program itself has to be extremely configurable and adaptable. And, the more adaptable a program is, the more it has to “be ready” for the user to do (maliciously, or accidentally). With this in mind, it is up to a good software engineer to test the program thoroughly, both on their own and by getting an independent party acting as the user to step in and poke around. They must exercise every aspect of the system as a user would to make sure they are no holes.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: