Ex 25.10 Describe five factors that engineers should take into account during the process of building a release of a large software system.
Target environment- The correct environment for the code must be selected for the system to be successful.
Documentation- This is the basis of every good project. Must be able to clearly see what every function does and how it does it.
Competition- The system should differentiate its self in the way it performs a task or has new abilities that are lacking in the competing software.
System quality- The system should be of sufficient quality and be free of errors in the most commonly completed functions.
Updates- The system should be maintain regularly to keep up with any updates on the servers or client machines.
Phillip Wilson's CSCI 362-01 Blog
HW27: Chapter 24
Ex 24.6 Explain why program inspections are an effective technique for discovering errors in a program. What types of error are unlikely to be discovered through inspections?
Program inspections are an effective technique for discovering errors in a program because it allows another person to inspect code that they did not write. Often times it is difficult for a person to find a mistake that they made but is glaringly obvious to someone else. Program inspections are unlikely to find run-time errors.
Program inspections are an effective technique for discovering errors in a program because it allows another person to inspect code that they did not write. Often times it is difficult for a person to find a mistake that they made but is glaringly obvious to someone else. Program inspections are unlikely to find run-time errors.
HW26: Chapter 23
Ex 23.6 Figure 23.14 shows the task duration for software project activities. Assume that a serious unanticipated setback occurs, and instead of taking 10 days, task T5 takes 40 days. Draw up new bar charts showing how the project might be reorganized.
T5 10 days
T5 40 days
HW25:Team Progress II
Our team has progress past the deadlines for the project and on the path for success. We completed all of our test cases. We re-numbered our test cases so that the script would output the results in the correct order.
HW24: Chapter 22
Ex 22.6 Fixed price contracts, where the contractor bids a fixed price to complete a system development, may be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay. Suggest how the use of such contracts may increase the likelihood that product risks will arise.
The use of fixed priced contracts may increase the likelihood of product risks because the contractor will have a limited amount of funds for the project. This may make the contractor not hire all the people that are necessary to complete certain projects. Also the contractors might tend to take more shortcuts to get he project finished on time cause functionality issues later on. They will also be less likely to include documentation and this will make it harder for modifications to be done by the company once the project has been completed.
The use of fixed priced contracts may increase the likelihood of product risks because the contractor will have a limited amount of funds for the project. This may make the contractor not hire all the people that are necessary to complete certain projects. Also the contractors might tend to take more shortcuts to get he project finished on time cause functionality issues later on. They will also be less likely to include documentation and this will make it harder for modifications to be done by the company once the project has been completed.
HW22: Chapter 17
Ex 17.10 Your company wishes to move from using desktop applications to accessing the same functionality remotely as services. Identify the risks that might arise and suggest how these risks might be reduced.
When moving from local desktop applications to remote services, there is the possibility of losing access due to network issues. This would cause all work that requires those assets to come to a complete stop. To resolve this, there could be a local server that users could work from then the server would update the remote service once connection was restored. There is also security risks involved with using a remote service. Strict security standards would have to be enacted to prevent the leak of personal/financial information.
When moving from local desktop applications to remote services, there is the possibility of losing access due to network issues. This would cause all work that requires those assets to come to a complete stop. To resolve this, there could be a local server that users could work from then the server would update the remote service once connection was restored. There is also security risks involved with using a remote service. Strict security standards would have to be enacted to prevent the leak of personal/financial information.
HW21: Chapter 20
Ex 20.10 You work for a software company that has developed a system that provides information about consumers and that is used within a SoS by a number of other retail businesses. They pay you for the services used. Discuss the ethics of changing the system interfaces without notice to coerce users into paying higher charges. Consider this question from the point of view of the company’s employees, customers, and shareholders.
It is unethical to change the interfaces to coerce the clients into paying higher charges without notifying the clients that these changes are coming in the future. Doing this could cause the current clients to look for another service. Some shareholders would welcome this because they would be able to make a quick buck and the sell there shares. This could end up hurting the employees because the shares worth could nose dive once a lot of consumers have left and many companies give their employees shares as bonuses.
It is unethical to change the interfaces to coerce the clients into paying higher charges without notifying the clients that these changes are coming in the future. Doing this could cause the current clients to look for another service. Some shareholders would welcome this because they would be able to make a quick buck and the sell there shares. This could end up hurting the employees because the shares worth could nose dive once a lot of consumers have left and many companies give their employees shares as bonuses.
HW20: Chapter 19
Ex 19.3 Why is it impossible to infer the emergent properties of a complex system from the properties of the system components?
Complex systems do not get their properties from just the properties of the system components. It is a combination of the the properties and how they interact with each other.
Complex systems do not get their properties from just the properties of the system components. It is a combination of the the properties and how they interact with each other.
HW19: Team Progress I
My group first chose SugarLab as our project but soon decided to change to Amari. After Deliverable #2, we fell behind due to having to many issues with getting Amari going. Matplotlib was found by Jan-Michael and we all agreed it was probably the better choice to go with. We have been making great progress after switching.
HW18: Chapter 18
Ex. 18.4 Define an interface specification for the Currency Converter and Check credit rating services shown in Figure 18.7.
Currency Converter Interface
Inputs: Currency type, Amount of Currency, currency to be converted to.
Operations: getExchangeRate(), convert(currency1, currency2),
Outputs: currencyContversion
Exceptions: Invalid Currency, Invalid Amount
Check Credit Rating Interface
Inputs: SSN, DateOfBirth
Operations: getCreditScore(SSN, DateOfBirth)
Outputs: creditScore
Exceptions: invalidSSN, invalidDoB
Currency Converter Interface
Inputs: Currency type, Amount of Currency, currency to be converted to.
Operations: getExchangeRate(), convert(currency1, currency2),
Outputs: currencyContversion
Exceptions: Invalid Currency, Invalid Amount
Check Credit Rating Interface
Inputs: SSN, DateOfBirth
Operations: getCreditScore(SSN, DateOfBirth)
Outputs: creditScore
Exceptions: invalidSSN, invalidDoB
HW17: Chapter 16
Ex 16.9 Design the interfaces of components that might be used in a system for an emergency control room. Yous should design interface for a call-logging component that records calls made, and a vehicle discovery component that, given a post code (zip code) and an incident type, finds the nearest suitable vehicle to be dispatched to the incident.
HW16: Chapter 9
Ex 9.8 Briefly describe the three main types of software maintenance. Why is it sometimes difficult to distinguish between them?
Fault repairs to fix bugs and vulnerabilities:
These are coding, design and requirement errors. The cost from least to most: coding; design; requirement.
Environmental adaptation to adapt the software to new platforms and environments
This is when a system's hardware or software is no longer supported or has been upgraded.
Functionality addition to add new features and to support new requirements
When requirements change and a new feature needs to be added to support the change.
The line between fixing bugs and functionality addition is a little blurry in that a requirement could have been overlooked in the original design phase or it could be a completely new requirement.
9.10 Do software engineers have a professional responsibility to develop code that can be easily maintained even if their employer does not explicitly request it?
Yes, software engineers are hired to make code that follow good programming guidelines. If they follow those guidelines, the code will be easily maintained without that engineer.
Fault repairs to fix bugs and vulnerabilities:
These are coding, design and requirement errors. The cost from least to most: coding; design; requirement.
Environmental adaptation to adapt the software to new platforms and environments
This is when a system's hardware or software is no longer supported or has been upgraded.
Functionality addition to add new features and to support new requirements
When requirements change and a new feature needs to be added to support the change.
The line between fixing bugs and functionality addition is a little blurry in that a requirement could have been overlooked in the original design phase or it could be a completely new requirement.
9.10 Do software engineers have a professional responsibility to develop code that can be easily maintained even if their employer does not explicitly request it?
Yes, software engineers are hired to make code that follow good programming guidelines. If they follow those guidelines, the code will be easily maintained without that engineer.
HW15: Chapter 15
Ex 15.10 The reuse of software raises a number of copyright and intellectual property issues. If a customer pays a software contractor to develop a system, who has the right to reuse the developed code? Does the software contractor have the right to use that code as a basis for a generic component? What payment mechanisms might be used to reimburse providers of reusable components? Discuss these issues and other ethical issues associated with the reuse of software.
When in the contract phase the contractor needs to clearly define what his acceptable with the code after they have developed it. It is up to the two parties on how to go about code reuse. It certain circumstances it might be easier for both for the code to serve as a jumping off point for later projects that will not require the contractor. The rights for code reuse should be dictated in the contract.
When in the contract phase the contractor needs to clearly define what his acceptable with the code after they have developed it. It is up to the two parties on how to go about code reuse. It certain circumstances it might be easier for both for the code to serve as a jumping off point for later projects that will not require the contractor. The rights for code reuse should be dictated in the contract.
HW14: Testing Reflections
Testing is probably the most dreaded word to most developers. Even though the proper way to develop is by having clear test design, it still puts a drag on the developer. We must think of the problem were are trying to resolve by code but also think about how to reliably test it after we are finished. Most of my classes so far, I have used the code and debug way of coding. This has caused certain assignments to take much longer than they should have. I usually end stopping and rethinking how I am trying to solve the problem. Usually coming up with an idea on how to test the end product. I would save myself a lot of time if I wasn't so stubborn and went to the second route first.
The different ways of thinking of testing bring to light some issues. For example, using testing to show the software works. As it is tested more the likeliness of it being reliable decreases because the likeliness of finding a bug increases. It's a conundrum for most people's minds because one would think that as you test all the possible cases, it would increase the confidence that the program is reliable.
Having a test that is unaware of the structure of the code is best because this person will not be biased. But if they do not have enough information about the objective of the code, they may make test that are superfluous. There is a balance between a tester having some knowledge and having too much bias. For certain small unit testing the programmer and tester are one in the same. The programmer must have freedom to code in the required functionality but they must also test as they go. This can lead to the programmer just coding and debugging.
HW13: Chapter 8
8.7 Write a scenario that could be used to help design tests for the wilderness weather station system.
The agency responsible for monitoring the risk of wild fire in California needs to collect information on rainfall, wind and temperature. They send a query to all the stations in a region to get this data and process it.
8.10 A common approach to system testing is to test the system until the testing budget is exhausted and then deliver the system to customers. Discuss the ethics of this approach for systems that are delivered to external customers.
The ethics for testing a system until the testing budget is depleted is a questionable one. For some products that is the most that can be expected with out end users getting there hands on it. Most developers and engineers think about a process differently that the average end user. But for other systems, it is obvious that all possible test case were not written due to time/budget concerns. Turning over a system like this is unethical in that it is not truly fulfilling what the customer has paid for. This often times costs the customer money.
The agency responsible for monitoring the risk of wild fire in California needs to collect information on rainfall, wind and temperature. They send a query to all the stations in a region to get this data and process it.
8.10 A common approach to system testing is to test the system until the testing budget is exhausted and then deliver the system to customers. Discuss the ethics of this approach for systems that are delivered to external customers.
The ethics for testing a system until the testing budget is depleted is a questionable one. For some products that is the most that can be expected with out end users getting there hands on it. Most developers and engineers think about a process differently that the average end user. But for other systems, it is obvious that all possible test case were not written due to time/budget concerns. Turning over a system like this is unethical in that it is not truly fulfilling what the customer has paid for. This often times costs the customer money.
HW12: Mythical Man Month
The Mythical Man Month compares large system programming to a tar pit. The more an animal struggles to break free from the pit, the farther it falls and more stuck it gets. For developers, the complexity of a large system compounds when trying to resolve small issues and more arise. Further pulling down productivity. Optimistic scheduling of completion of a project is the cause of most projects being late and over budget. He goes on to say that part of this is because programming in its nature of creating attracts optimists. I agree with that statement. The thought of creating something new or doing an old task in a better way is what attracts me to this field. I have fallen into the trap of being too optimistic with my time when programming and something that was estimate to take 10 hours ends up taking me over 30 hours. Testing and debugging is the demise of most developers that are already behind.
The man-month concept is wrong in that it assumes that men and months are interchangeable. Most of the time the first thing a manager that does not understand development will start adding men to a project after it is already behind. I once saw this at a company I previously worked for. The software they were working on was not meeting certain deadlines for individual functions that were to be added to the live version. This was partially because before the development team could finish the given assignments, they were given new specifications on other pieces that were deemed more critical roll out. The VP of development decided they would hire 4 new developers to finish the previous functions that were started and have the current team get started on the new functions. This of course did nothing to speed up the development schedule. Most of the developers became annoyed with the fact that they were spending more time showing the new guys what they had started then actually writing code. One of them even quoted the mythical man-month in a meeting. Fig 2.4 shows how once there are too many men added to a project, the amount of months necessary for completion go up. This is due the intercommunication that must go on for the newly added group to get up to speed. Once it is determined that the project is behind, most managers will not reschedule the completion date which I feel is the best solution when the deadline has been underestimated.
Breaking up the development team into designated roles removed from the actual coding can serve to speed up the development process. No longer will the programmer be concerned with making test cases and other supporting tasks. The main coder will be able to focus on getting the function completed. I believe separating the roles is the way most companies are heading. New graduates often get jobs as testers or quality assurance specialists. The ones actually producing the product have many years of experience.
Conceptual integrity is often overlooked and causes a program to be delayed by the addition of new “smarter” functions. In the case of my previous employer, they started the project with a few very clear goals setup. Over the year it was being developed, so many things were added and/or changed that its focus did not even remotely resemble the original plan. They were perpetually going between architecture design and implementation without ever getting to realize the finished product
The man-month concept is wrong in that it assumes that men and months are interchangeable. Most of the time the first thing a manager that does not understand development will start adding men to a project after it is already behind. I once saw this at a company I previously worked for. The software they were working on was not meeting certain deadlines for individual functions that were to be added to the live version. This was partially because before the development team could finish the given assignments, they were given new specifications on other pieces that were deemed more critical roll out. The VP of development decided they would hire 4 new developers to finish the previous functions that were started and have the current team get started on the new functions. This of course did nothing to speed up the development schedule. Most of the developers became annoyed with the fact that they were spending more time showing the new guys what they had started then actually writing code. One of them even quoted the mythical man-month in a meeting. Fig 2.4 shows how once there are too many men added to a project, the amount of months necessary for completion go up. This is due the intercommunication that must go on for the newly added group to get up to speed. Once it is determined that the project is behind, most managers will not reschedule the completion date which I feel is the best solution when the deadline has been underestimated.
Breaking up the development team into designated roles removed from the actual coding can serve to speed up the development process. No longer will the programmer be concerned with making test cases and other supporting tasks. The main coder will be able to focus on getting the function completed. I believe separating the roles is the way most companies are heading. New graduates often get jobs as testers or quality assurance specialists. The ones actually producing the product have many years of experience.
Conceptual integrity is often overlooked and causes a program to be delayed by the addition of new “smarter” functions. In the case of my previous employer, they started the project with a few very clear goals setup. Over the year it was being developed, so many things were added and/or changed that its focus did not even remotely resemble the original plan. They were perpetually going between architecture design and implementation without ever getting to realize the finished product
HW11: Chapter 6
6.4 Draw diagrams showing a conceptual view and a process view of the architectures of the following systems:
A ticket machine used by passengers at a railway station
Concept:
Process:
A compute-controlled video conferencing system that allows video, audio, and computer data to be visible to several participants at the same time.
Conceptual:
Process:
A robot floor-cleaner that is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions.
Conceptual:
Process:
A ticket machine used by passengers at a railway station
Concept:
Process:
A compute-controlled video conferencing system that allows video, audio, and computer data to be visible to several participants at the same time.
Conceptual:
Process:
A robot floor-cleaner that is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions.
Conceptual:
Process:
HW10: Chapter 5
5.3 You have been asked to develop a system that will help with planning large-scale events and parties such as weddings, graduation celebrations, and birthday parties. Using an activity diagram, model the process context for such a system to that shows the activities involved in planning a party (booking a venue, organizing invitations, et.) and the system elements that might be used at each stage.
5.5 Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrollment, so the registration process must include checks that places are available. Assume that the student accesses an electronic course catalog to find out about available courses.
5.7 Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine.
5.8 Draw a sequence diagram for the same system. Explain why you might want to develop both activity and sequence diagrams when modeling the behavior of a system.
5.5 Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrollment, so the registration process must include checks that places are available. Assume that the student accesses an electronic course catalog to find out about available courses.
5.7 Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine.
5.8 Draw a sequence diagram for the same system. Explain why you might want to develop both activity and sequence diagrams when modeling the behavior of a system.
HW9: Reflections
Programming will continue to be the hot career choice that
we will hear about on the news. It will continue to be both extremely
competitive and highly sought after. Hopefully more companies will realize that
they cannot simple rely on just developers and project managers to develop
their systems efficiently. True software engineers will be needed to manage the
developers, project managers and even the client. They will make sure what they
are creating is held up to the highest standards. The risk will continue to
increase as more crucial systems will be put under the watchful eye of a piece
of software. The software engineering process will be needed to ensure safety
because a failure could cause the loss of life.
In 9
predictions for the future of programming, the author says projecting where
technology and processes will be in even 5 years is more like guesswork. I
agree with this. Growing up in the 90’s before internet access was widely
available to today where you see people with their eyes glued to a slim ‘phone’
where they can essentially do all the same things with it as a full PC shows
how far tech has come. This has triggered other devices that function fine
without an internet connection to be linked to the internet. The user can now
control their thermostat from their phone, see who is at their front door, etc.
The push in the general public is for there to be more
programming taught in schools. Just like learning another language, it is
easier to learn at a younger age. Progression in new ways of thinking will develop
quicker and more rapidly.
There is also a naïve assumption that everyone should learn
to program. Not everyone needs to learn how to program, nor can everyone do it
efficiently. A doctor doesn’t need to waste their time learning to make a new
function within their EMR software when a skilled professional or company can
do it much faster and at lower cost. Time is money to most working
professionals. The may not know best practices and will not have time to check
for new errors cause by the modification.
We already see today how much smart phones have taken over
people’s lives. This is evident walking down the street. You’ll see many people
using their phones but few using them for making a phone call. People are using
them to text each other, update social media and surf the internet. So I agree
that smartphones will gain so much more functionality that being used as a
phone will be a secondary function. The prospects are boundless with what they
can be used for and what can be developed to use the phone as hardware.
Bigger databases are already being created and will only get
bigger. The monitoring of users will grow and this is where a system engineer
needs to ensure what they are developing lives up to professional standards.
Scripts will also be heavily implemented through transcoding robots.
Simplifying the workflow of engineers. Simplified script languages will come
along with it.
HW8: Chapter 2
2.1 Suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems. Explain your answer according to the type of system being developed:
A system to control antilock braking in a car:
The waterfall method would be best for this system. The specifications and requirements are known at the beginning of the process. At the end of the development phase, the system would have been tested and issues resolved before it ever reaches the customer. This keeps the customer and the company safe.
A virtual reality system to support software maintenance:
The incremental process would work best for this type of system. Focusing on one aspect at a time will ensure there will be some form of a working system. VR is a newer technology so many things are having to be done for the first time and you can't just go to stackoverflow.
A university account system that replaces an existing system:
I would use the integration and configuration model for this type of system. The features from the previous system that were heavily used would be the first to be brought over and improved. The healthcare company used this method when switching their electronic medical records software.
An interactive travel planning system that helps users plan journeys with the lowest environmental impact:
I believe the incremental approach would be the best model for this system. The first step would have to be figuring out how to calculate the lowest environmental impact. Then the user interface would come next. Some functions would have to be changed and new functions may end up being added to give the best user experience.
A system to control antilock braking in a car:
The waterfall method would be best for this system. The specifications and requirements are known at the beginning of the process. At the end of the development phase, the system would have been tested and issues resolved before it ever reaches the customer. This keeps the customer and the company safe.
A virtual reality system to support software maintenance:
The incremental process would work best for this type of system. Focusing on one aspect at a time will ensure there will be some form of a working system. VR is a newer technology so many things are having to be done for the first time and you can't just go to stackoverflow.
A university account system that replaces an existing system:
I would use the integration and configuration model for this type of system. The features from the previous system that were heavily used would be the first to be brought over and improved. The healthcare company used this method when switching their electronic medical records software.
An interactive travel planning system that helps users plan journeys with the lowest environmental impact:
I believe the incremental approach would be the best model for this system. The first step would have to be figuring out how to calculate the lowest environmental impact. Then the user interface would come next. Some functions would have to be changed and new functions may end up being added to give the best user experience.
HW7: Reflections
Developing the requirements needed seems to be a critical
aspect of engineering. When identifying the requirements, it also a good time
to think about test case that can cause the software to fail. Think about the
relationship between functional and non-functional requirements and where
issues can arise. Continual testing is needed as the software is developed and
maintained. In the Planning
for Failure in Cloud Applications article, the author mentions a tester
that simply removed the network cable to the test database server. This brought
out a new case to which had not been gracefully handled by an exception in the
code.
Also security in new technology should be properly tested,
especially if it is going to be mandated to be on all devices to which it deals
with. An unresolved security flaw can cause issues for all the user’s with that
device and allow for unwarranted access.
Test Driven Development is a good way of improving an application
from the beginning. Each code will incrementally resolve test cases. As the
software ultimately builds in complexity more and more test case will need to
be added. Documentation should also be updated and adjusted as changes are
made.
HW6: Chapter 4
4.5 Write plausible user requirements for the following:
An unattended petrol (gas) pump system that includes a credit card reader. The customer swipes the card through the card reader, then specifies the amount of fuel required. The fuel is delivered and the customer's account debited.
The cash-dispensing function in a bank ATM.
In an Internet banking system, a facility that allows customers to transfer funds from one account held with the bank to another account with the same bank.
4.6 Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.
The requirements should all be kept in the same document but the can be differentiated using some form of notation. Non-functional requirements will be grouped with the functional requirements to which they affect. This could be done in an outline format for each functional requirement.
4.7 Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.
An unattended petrol (gas) pump system that includes a credit card reader. The customer swipes the card through the card reader, then specifies the amount of fuel required. The fuel is delivered and the customer's account debited.
- The pump should always be ready to accept input.
- The pump should check the card information for validity before proceeding.
- The pump should ask for the amount of fuel to be dispensed.
- The pump will stop dispensing fuel once the user inputted amount has been reached.
- The customer's account will then be debited.
The cash-dispensing function in a bank ATM.
- The ATM will take input from the customer has swiped/input there card into the reader.
- The ATM will ask for a pin.
- The ATM will then ask for the amount to dispensed.
- The ATM will then dispense the desired amount.
- The ATM will terminate access to the user's account.
- The ATM will return to a ready state for input.
In an Internet banking system, a facility that allows customers to transfer funds from one account held with the bank to another account with the same bank.
- Prompts user for the account number to which they would like to transfer funds to.
- Confirms the account is with the same bank.
- Prompts user for the amount to transfer and has the user confirm.
- Checks the user's account to ensure they have the funds.
- Credits the specified account and debits the user's account.
4.6 Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.
The requirements should all be kept in the same document but the can be differentiated using some form of notation. Non-functional requirements will be grouped with the functional requirements to which they affect. This could be done in an outline format for each functional requirement.
4.7 Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.
- Withdrawal from the ATM.
- Deposit into the ATM to the account.
- Checking the balance of multiple accounts linked to a debit account.
- Print receipt for all of the above functions.
- Checks withdrawal amount to the amount of cash in the machine.
- Checks withdrawal amount to the amount of money in the account.
HW5: Reflections
When engineering a new software program, risks need to be
evaluated and directly tested. It is the duty of the engineer to see that there
are safety elements in place to handle these risk if they do occur. If proper
testing and follow up is not done, tragic cases such as those that happened
with the Therac-25 can occur. With the Therac-25 issues, software was reused
from another device that had hardware fail safes to prevent improper use. The
software was not tested with the new hardware which did not have the hardware
fail safes until they were assembled at the hospital. The risk of over
radiating a patient do to improper use or fault was not tested with new hardware
because it was assumed it would not have any issues due to it being reused
software. Therefore good software engineering practices were not followed. The application
was built in such a way that proper testing was nearly impossible.
The FBI wasted millions of dollars by not following software
engineering processes. They built a blueprint for a piece of software that was
doomed from the start. Many of the features specified could have been provided
at much lesser expense by customizing off the shelf software. The project was
place into the hands of a person who had no project management experience. Unattainable
deadlines were put in place and the software was behind schedule from the get
go. The software was plagued by system upgrade issues. Multiple leadership
changes also affected the direction of the development because the goals were changed.
Eventually it was determined that the software developed as VCF was so poorly written
that it would be better to start over with a new project.
Sentinel was to replace want was supposed to be replaced by
VCF. Six years later, Sentinel was a two years behind and still lacked common
features found even in the most basic of word processors. The beta program
failed during testing procedures. And two years after the final product was
delivered the software still had major issues with indexing and searching case
files. The indexing function was not popular with the end users due to its
functionality. This aspect should have been tested and refined with user input
to make it beneficial to the agents that would be using it. The searching
function was too hard to use for most of the agents, making it useless.
The FBI is not the only government institution that has
wasted tax payer dollars by poor software engineering principles. NASA has
several catastrophic failures due to poor software engineering. The most famous
of these the Mars Climate Orbiter (MPL). The MCO was to enter a low orbit
around the planet but entered an orbit that was much lower than expected. An investigation
into how this happened revealed that a failure to use metric
units in the coding of the software for the control of the thrusters. They were
instead done in English units. Simple test cases could have been setup to test
for this issue before the craft even left the earth.
HW4: Chapters 11 & 12
11.4
The common characteristic of all architectural styles geared towards software fault tolerance is redundancy.
11.7
N-version programming would not be a wise decision because if there were a failure it could result in the lose of life.
11.9
Exceptions should be explicitly handled in a system that is intended to have a high level availability because the software needs to be able to continue running. The software can allow for human error and get the correct information instead of shutting down.
12.5
The software should alert the conductor if connection to track status is disrupted.
The software should apply the brakes if the train is going above the speed limit.
The software will stop the train if the next segment of track is in a red light condition.
The software will monitor and compare current speed to the speed limit of upcoming segments of the track.
The software will allow the train to move when the track turns into a green condition.
The common characteristic of all architectural styles geared towards software fault tolerance is redundancy.
11.7
N-version programming would not be a wise decision because if there were a failure it could result in the lose of life.
11.9
Exceptions should be explicitly handled in a system that is intended to have a high level availability because the software needs to be able to continue running. The software can allow for human error and get the correct information instead of shutting down.
12.5
The software should alert the conductor if connection to track status is disrupted.
The software should apply the brakes if the train is going above the speed limit.
The software will stop the train if the next segment of track is in a red light condition.
The software will monitor and compare current speed to the speed limit of upcoming segments of the track.
The software will allow the train to move when the track turns into a green condition.
HW3: Chapter 10
10.6 Explain why it is reasonable to assume that the use of dependable processes will lead to the creation of dependable software.
It is reasonable to assume that the use of dependable processes will lead to the creation of dependable software because if all the steps of the process are followed, then it will resolved any issues before the software is finished. The software will have been tested extensively and any issues will have been resolved.
10.10 It has been suggested that the need for regulation inhibits innovation and that regulators force the use of older methods of systems development that have been used on other systems. Discuss whether or not you think this is true and the desirability of regulators imposing their views on what methods should be used.
The code of ethics means the software should meet the highest professional standards. And regulations help insure this by having proving processes to check the software. Regulations should not be enforce when in the early stage of solving a complex issue. Once solution is found, it should be vetted following some sort of testing regulation.
It is reasonable to assume that the use of dependable processes will lead to the creation of dependable software because if all the steps of the process are followed, then it will resolved any issues before the software is finished. The software will have been tested extensively and any issues will have been resolved.
10.10 It has been suggested that the need for regulation inhibits innovation and that regulators force the use of older methods of systems development that have been used on other systems. Discuss whether or not you think this is true and the desirability of regulators imposing their views on what methods should be used.
The code of ethics means the software should meet the highest professional standards. And regulations help insure this by having proving processes to check the software. Regulations should not be enforce when in the early stage of solving a complex issue. Once solution is found, it should be vetted following some sort of testing regulation.
HW2: Responses
The concept of a piece of software can be boiled down to 3
related concepts: data, the relationship between those two pieces of data and
the algorithms/functions used to process the data. As the complexity goes up so
do the issues that can arise from modifications in code to do new functions. They
can adversely affect other pieces to the program. Having multiple developers
and storage locations for code can also greatly impact productiveness. The No
Silver Bullet article states there is not one single development that can
provide “even one order-of-magnitude” of improvement in software engineering. Google
has tried to resolve some of this by having a “monolithic” codebase. The
advantages of this are extensive code sharing and reuse. This cuts down on time
spent creating a piece of software. Allowing them to focus more time on the
more complex tasks.
This also is brought up in the Kode Vicious response to
cherry picking. At some point an engineer will realize that they will be better
off spending their time merging rather than picking out just the parts they
need. By Google having the monolithic codebase, it is all there for everyone to
use. If a team wants to rely on another teams’ code, they can do so directly.
Instead of picking through another repository and spending time bring over, it’s
already there for the taking. I believe Google has come very close into
creating a “silver bullet” for their ideals in software engineering. There are
issues with this structure. It creates greater overhead cost in hardware and
maintaining code. One way other software engineers have tried to manage the maintenance
issue is with the use of distributed version control systems like Git. Google
has started using Git for its Android and Chrome teams because of their
collaborations with outside partners.
The silver bullet Google has created is more of a shotgun
shell in that it uses many smaller pieces to solve larger problems. Other early
breakthroughs like high-level languages have allowed more complex problems to
be solved. But with those high-level languages has come a greater dependence on
them. It seems technology is always advancing and resolving current issues.
Then as those issues are resolved, even more complex issues will follow. It is
a never ending cycle. There will always remain the issue of verifying and
testing new software. The methods to test vary just as much as the methods that
could have been used to solve them. The documentation for which also takes time
but is a crucial part of software engineering.
HW1: Chapter 1
1.3 What are the four main attributes that all professional software should possess? Suggest four other attributes that may sometimes be significant.
4 Essential attributes of good software:
1.8 Discuss whether professional engineers should be licensed in the same way as doctors or lawyers.
Professional engineers should be license in the same way as doctors or lawyers because they can affect the lives of many people. They ensure things are created and maintain properly. If they do not do their job correctly, then it can affect a whole population.
1.9 For each of the clauses in the ACM/IEEE Code of Ehtics shown in Figure 1.4, propose an appropriate example that illustrates that clause.
1.10 To help counter terrorism, many countries are planning or have developed computer systems that track large number of their citizens and their actions. Clearly, this has privacy implications. Discuss the ethics of working on the development of this type of system.
Counter terrorism surveillance is sadly a necessary evil in today's world. The system should try to target just citizens suspected of committing future terrorist acts or previously committed acts. The reality is it is extremely hard to pinpoint these people without putting out a dragnet that will sadly capture information on ordinary citizens. The engineers on this software walk a then line because this type of system can very easily be misused.
4 Essential attributes of good software:
- Acceptability
- Dependability
- Efficiency
- Maintainability
4 other attributes:
- Functionality
- Documentation
- Good naming convention
- Should install with minimal outside required software
1.8 Discuss whether professional engineers should be licensed in the same way as doctors or lawyers.
Professional engineers should be license in the same way as doctors or lawyers because they can affect the lives of many people. They ensure things are created and maintain properly. If they do not do their job correctly, then it can affect a whole population.
1.9 For each of the clauses in the ACM/IEEE Code of Ehtics shown in Figure 1.4, propose an appropriate example that illustrates that clause.
- Public - A software engineer creates an app to share news
- Client and Employer - The engineer creates the software to the clients specifications so long as it cannot do harm to the public.
- Product - The finished product is reliable.
- Judgement - The engineer decides to not continue a project because it may be used for harm.
- Management - The manager of engineers does not allow the production of a application to spy on other members of the public.
- Profession - An engineer keeps the public interest at the forefront of their career.
- Colleagues - An engineer helps another engineer finish an aspect of an app.
- Self - Learn new programming languages and new ways of creating software.
1.10 To help counter terrorism, many countries are planning or have developed computer systems that track large number of their citizens and their actions. Clearly, this has privacy implications. Discuss the ethics of working on the development of this type of system.
Counter terrorism surveillance is sadly a necessary evil in today's world. The system should try to target just citizens suspected of committing future terrorist acts or previously committed acts. The reality is it is extremely hard to pinpoint these people without putting out a dragnet that will sadly capture information on ordinary citizens. The engineers on this software walk a then line because this type of system can very easily be misused.
HW0: Introduction
My name is Phillip Wilson and I am originally from Corona California. My family moved out to Summerville in 2005 and I finished high school at Summerville High. I am currently a Junior at CofC currently pursuing a degree in computer science. I have been working in IT for the past 5 or so years from a PC tech position to senior level helpdesk. I hope to further my career in IT to an administrator then Engineer position.
Subscribe to:
Comments (Atom)











