Impromptu Meeting To Fix Deliverable 3

Today Nelson, Crendall and I attempted to fix at least some of our deliverable 3. The fixes we included were changes to the code and generalizing the test generation, as well as changes to the document. Changes to the document included things such as names, date, context, and filling out in greater detail how our tests work. Test cases requirements were specified further than reference,  and the how-to section was revamped all together to specify how to add and remove tests as opposed to how to run the framework in general.

Some Thoughts on Chapter 22

None of the important easy to see goals nor the problems of managing a software engineering project listed were surprising. We know by now that our projects are intangible, unique, and always changing, and actually doing what we say we will do is important to keeping customers happy. None of the responsibilities of the project manager were particularly surprising either.

That being said, risk management, managing people, and teamwork are all very important to the success of a software project. On some levels I feel like the management of people will lend itself to having certain elements of teamwork. Someone who is good at managing people is going to facilitate communication especially. While most of the important points in teamwork and people management seem obvious, they are obviously important and not always done correctly despite this.

Deliverable 3 Complete

All of our members showed for our last meeting before deliverable 3 was due, which was nice. Together we targeted different parts of the problem, such as the pdf file, oracle, test specification templates, and the script itself.

We encountered some problems getting it to compile correctly at first, at least having it do so automatically. We soon passed that first problem using the java compiler, and ran into other problems actually executing everything. Unfortunately these setbacks with java and the java compiler set us back quite a few hours.

While some of us were tackling that problem we were able to complete the other parts of the project and conceptualize what was needed to be done.

Unfortunately while we've sketched out the rest of the program this one problem proved rather difficult and as of the time of this time of posting is still a roadblock for us.

Chapter 21 - Aspect-orientated Software Engineering

Aspect-orientated software engineering certainly seems useful. We've looked at a number of software engineering projects that failed due to poor organization, planning, and communication. Aspect-orientated software engineering seems to directly combat that by identifying relationships between requirements and components, beyond the level of a simple T chart or a bunch of circles connected with lines.

The separation of concerns concept is something that we've been taught since the beginning, as methods and subroutines do exactly that. We were taught to make each function do one thing, and if something in a program appears multiple times, we should probably make a subroutine out of it. And while it may be more time consuming to piece together a puzzle with smaller pieces instead of big pieces, you can get a much tighter and problem free fit from the smaller pieces.

Updating Deliverable 2 and Onward

Before the weekend our team met and updated our previous deliverable, which included the test plan for our project. Our tests were planned more specifically with expected input and output, as well as a clear mapping form test to requirement being tested. The system testing area was entirely cleaved as we're focusing on one method out of a class for the moment, with many other methods in that class needing multiple tests. Instead of only having the required 5 tests for deliverable 2 we devised 5 additional tests after fixing the previous 5 bringing our total up to 10. Our focus for the next meeting is intended to be on deliverable 3, as this meeting was to ensure that we can hit the ground running for the next meeting.

On Sunday our team met again to start on deliverable 3. This meeting we created the first 10 test files we intended to use and sketched out the scripting file, as well as the overall plan. We ensured our repository had the necessary file system and our conceptual design for the rest of the deliverable was sound. With the completion of the test and us already knowing what the oracle should contain the script is the only piece that is really left.

Chapter 18 - Distributed Systems Issues

A distributed system is defined in the book as "...a collection of independent computers that appears to the user as a single coherent system." This makes me wonder if a system that allows the user to pick from which server to run, such as a video game, is considered a distributed system or not. Would it depend on whether or not that server was actually on several boxes, or would it not be one if it was one box per server?

The advantages and disadvantages of a distributed system seem obvious. More redundancy, more compatibility, and scalability. While response time may be an issue, these seems like issues that can be solved with good design or scalability - though like in all systems, security is an issue.

In the discussion of peer-to-peer systems, it is mentioned that Intel and Boeing have implemented a version of them to work on hard computations. It's mentioned that this software runs while the workers have gone home, but I wonder if they run whilst the normal business day is going? Does this adversely affect the performance of the individual local computers if so, or is the priority set very low?

Chapter 17

Component-based software engineering makes a lot of sense from an economical and even an efficient perspective, which I heartily respect. All of the component characteristics defined are characteristics that anyone at this stage would have discussed previously. The exception could be composable - which means all external interactions must take place through publicly defined interfaces - but this is an easy enough concept to grasp.

The concept that a component has two interfaces - the "requires interface" and the "provides interface" - is something I hadn't really thought about before. I'd certainly thought of the provides interface - as ultimately that is what I'm interested in. Obviously I had considered that I had to provide input to the component to get appropriate output, however I think I was stuck in the idea of providing it in the signature that I expect to get my output back from. Providing it beforehand, especially if the input is a large set of data such as a database, makes more sense efficiency wise. I'm sure these are thoughts that I've had before, but they were gleaned over and I never thought of the concept properly.

Team Meeting for Deliverable #2

Unfortunately our team meeting on Sunday did not have all of our members in attendance. Me, Brendan, and Crendall managed to physically be there, though J Roth did manage to aid us and communicate through the Google document where we constructed our deliverable. The construction of the deliverable was not particularly difficult, though we had to negotiate schedules and what tests we first wanted to do.

Initially we went to page 209 of our book as instructed. The page didn't detail any structure for our plan like we hoped, and the link it sent us to was dead. Instead we used the link you had and based our structure on that. I made the document and while we all discussed it I typed, and later Crendall was the one who uploaded it to svn after saving it as a pdf. We know most of our resources will be sunk into deliverable number 3 since that's where the scripting will come into play, and we know we have to research how to manually get the project to compile.

Legacy Information Systems

I was previously unaware that legacy information systems were so important to so many people. When I hear of a legacy system I normally think of an outdated system that's been in use for a long time and is still in use even now. I imagined that most companies had at least a slightly updated information system at their back end to keep everything running. Of the three solutions to the problems of legacy systems, I hadn't previously thought of migration. I suppose it just seems similar to wrapping to me - I'm curious how it's possible to move the system to a more flexible environment while keeping everything the same without simply throwing a wrapper on it.

It's also interesting that if a system can be maintained within an acceptable budget then the system isn't usually considered a legacy system - and given that most companies apparently have legacy systems, that's a lot of companies over-budget in this one area. It seems like this big problem would have gathered more interest and work in the field.

It seems to make sense that lazy people who aren't terribly concerned about the long-term make wrapping the most popular choice of solution - especially given it seems to take the least work in comparison. Migration work is an in-between between redevelopment and wrapping in a way I didn't expect - it seems to be essentially copying the system over with everything wrapped in the actual code. You're just fitting the old data in a new form. It comes at no surprise that testing is important and may take most of an engineer's time.