V4 SPradhan Reflections

From SoftwarePractice.org

At the start of the semester I though this subject was just like any other subject, the same boring methods and ways of thinking. Little did I know that this subject was all about thinking out of the box.

During milestone 1 I realised our narratives and personas did not allow us to derive hard requirements from them. They were too vague and ambiguous talking about the system in general rather than the specific testable items. I learnt that the personas and narratives exist to establish what the stakeholders are expecting from the system rather than how they intend to use it.

During the course of milestone 1 I understood what was meant by the term "key contextual factors" and how to assess whether they were a risk, constraint and/or enabler to the system. I realised that the best way to find contextual factors is by breaking them down into main groups such as:

• market and competitive
• organisational
• technological
• policy

The quality attributes section has taught me a lot of what software engineers need to consider whilst developing a system. Its not essential to concentrate on satisfying all the quality attributes but rather to rate the attributes against each other and find the most relevant. The subject has taught me to do the more important elements of a system really well rather than doing everything to an average level.

I learnt its better to use a $10 rating system against each stakeholder rather than a random arbitrary number.

The subject has taught me that quality narratives have to be measurable. They need to contain actual values of response times, usage statistics, etc.

Different to personas and narratives, usage narratives are how the stakeholders will use the system rather than what they expect. This gives the software engineer an insight into the key operations in order to find critical sections of code where dependency is high.

I have also learned during this subject how to convert scenarios or a body of text into a list of requirements that might make up key components or abstract concepts. This is essential for a software engineer to do as this summarises the capabilities of the system which is ultimately going to have to be proven in order to achieve final acceptance and payment.

I also learned that the conceptual architecture can be significantly different to the implementation and execution architectures and this is quite acceptable. The conceptual architecture exists to provide an initial concept which assists the developers to start developing the system. During the process of creating the conceptual architecture I learnt that inter-component communication does not need to be labeled on the diagram is it is implied.

I understood the concept of data models and how parameters are passed between classes within the system. This is essential as it shows how data flows through the system and outlines the multiplicity of the system.

Use Case Maps taught me that each use case map corresponds to a certain function or capability of the system. It is almost like a test plan but to test the architecture rather than the final system. I also learnt the symbology of use case maps which I did not know before. I also learnt that a use case map is more effective if it contains markets on it which correspond to text which describes data flow and/or processing.

The study of execution architecture has taught me how the execution architecture can differ from the conceptual view as long as it has traceability. Similarly with the deployment view it taught me to consider how exactly we will be required to group processes to deploy it on the customers system.

The implementation architecture taught me that it is easier to create interfaces between components than having several connections between them. This allows the architecture to be simplified whilst maintaining the functionality.

Filling out a log books has taught me that it is essential to know what work you did on what date. This is beneficial if anything goes wrong to be able to trace it back to when you did the work.

Minutes provides you with objectives and tasking of what you need to do that week. I found that extremely useful in this subject.