Tag: software engineering

The 4Ps of Software Engineering

Software engineering is a set of processes carried out by people undertaking various practices and informed by an overarching paradigm.

Processes are a series of activities that move from an idea, problem, or opportunity to completed software delivered to users. Most processes include four phases-specification, development, validation, and evolution. Agile and lifecycle are two different process approaches to software development. 

People involved in software engineering include developers who do the work to enable users to interact with the software in some way. The customer, sometimes the user, makes decisions about the design. Maintenance staff (operations) launch the software and look after it once completed. Testers check that the software meets the original requirements set by the customer, and technical authors write user guides/manuals.

Practices are the specific activities a developer carries out to develop the system. Examples include analysing and modelling people’s problems, collecting user requirements writing code, and testing the system works. The order of the various practices is dictated by the process chosen.

A Paradigm is a set of practices linked together around a set of beliefs about developing software. The two most common paradigms are Object-oriented programming where software is built as a set of real-world objects with properties and behaviours, and Structured systems analysis where software is a set of functions operating on data.

Refactoring, Reuse, and Learning Design

The increase in digital technology in many fields has also brought software engineering language and practices into these areas. I studied Information systems and management at University, so I am more guilty than most for this trend. I have introduced rapid prototyping, the Capability Maturity Model, and daily stand-ups to my team’s work to name just a few.

Refactoring: The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure.

Martin Fowler

This week I have come across a company using ‘Refactoring’ as a term used in learning design. In software engineering, programmers use refactoring to describe going back to old code and cleaning it up. Refactoring is a continual process of improving code and reducing the number of lines while maintaining functionality. Code is usually written quickly to solve a functionality problem, so programmers revisit it, and rewriting it to run more efficiently. Reuse is a significant part of the refactoring process where a programmer copies some code from another programme to replicate the functionality and simplicity somewhere else quickly.

The company that I will not name used refactoring to describe unbundling a course and then restack it into different offerings. It is splitting a degree or Masters into its separate modules and then offering these individually or in groups of modules to other potential students. This might be offering the first 180 credits of a degree or a combination of modules from all three years into a certificate. It might also be offering working professionals the option of studying a single module that they need for work. The idea they tried to get across was that universities already have these bundles of modules that can be rearranged into courses that attract a wider audience, but I do not think the term quite works.

Reuse: An Engineering strategy where the development process is geared to reusing existing software

Ian Sommerville

After the session, I revisited my university notes to see if ‘refactoring’ was a marketing effort and taking liberties. I came across a line that I am not sure is mine or a direct quote from a book but refactoring ‘allows us to think about reuse of previous components or looking at alternative ways of doing things.’ Reuse is borrowing code from existing software to reduce the amount of code required to produce when developing a new system. I can’t help but feel that ‘reuse’ is a better technical term for what was implied, but it is not flashy. 

Let me know on Twitter if I am wrong or want to share other terms taken from software engineering misused (think Agile). We can have a group eye roll.

n.b. The rest of the presentation was excellent, and they had great ideas.