software-enginering-101

[software-enginering-101]

Always have requirements related to software versioning and reporting. You need a quick and easy way of knowing what the software is. In the case of safety critical software, you want to verify that the version is not corrupted by checking an expected checksum against a calculated checksum.

[software-enginering-101]

Making SW configurable is good. A couple of things to remember. Configurability can substantially increase the test effort and thus the cost. The more configurable the software settings, the more combinations and permutations of different settings to test. Also remember you need to provide a mechanism which allows the user to return to factory default in case they get themselves into a mess.

[software-enginering-101]

How should SW teams be managed?

There are methodologies like Scrum out there but should you go for something more bespoke?

Most organisations impose a hierarchy and expect leaders to lead - so how would a self organising team work?

Most organisations require weekly timesheets, so should you fit in with the organisational cadence. Most individuals work to a weekly cadence too - so why fight what seems natural by imposing a different sized sprint. I have started holding planning meetings on Monday and then review / reflectives on Friday. No daily scrums in-between. I also reserve the right to redirect the team if urgent priorities arise - regardless of what was planned.

Also large organisations are not easy to change to fit the Agile paradigm. They frequently force you down a waterfall approach with gated reviews like requirements review, preliminary and critical design reviews and test readiness reviews.

Organisational issues aside, if working on safety critical software then standards like DO178C and IEC61508 can impose work flows which are far from Agile in nature.

Don't get me wrong there is a place for Agile practices. Software Engineers and leads should understand Agile methodologies and workflow, they should also understand waterfall. A good lead should be able to adapt these to the needs of his team. Too often Agile evangelists can impose as rigid a structure and way of working as Waterfall.

Finally while working software is the ultimate goal, however the importance of documentation cannot be overstated - it reduces dependence on individuals. You need docs for:

Plans on config control, quality, verification, requirements and change management.

Requirements, design, build procedures, software loading procedures, test specs, test reports, release notes, software user guides.

When Agile says change is welcome, that's good but the impact of change on code, documentation and test needs to be considered and costed.