Instructor

Most projects have five phases:

1. Initiation: Here is where you set out the project scope, the goals, the organization of the project, its business case, its constraints, who the stakeholders are, what the risks are, the project controls, the reporting framework, etc.
2. Planning: This is where you build the roadmap to take you from Point A to Point B, which means creating a schedule of the tasks, deadlines and resources needed to complete everything on time.
3. Execution: The project begins and the project plan is put into action.
4. Monitoring & Controlling: To make sure the project is proceeding as planned, you need to set up mechanisms for monitoring progress. If the project isn’t proceeding as planned, work to control and resolve issues before they become problems.
5. Closing: Projects are temporary endeavors, so they eventually come to an end and need to be formally closed. But it’s not as simple as producing deliverables, there’s paperwork to sign off on, resources to reallocate and other loose ends to tie up.

   Prince Patel

Agile SDLC Model

In the agile methodology after every development iteration, the customer is able to see the result and understand if he is satisfied with it or he is not. This is one of the advantages of the agile software development life cycle model. One of its disadvantages is that with the absence of defined requirements it is difficult to estimate the resources and development cost. Extreme programming is one of the practical use of the agile model. The basis of such model consists of short weekly meetings – Sprints which are the part of the Scrum approach.

-Prince Patel

I found the different types of installation methods and the pros and cons of each to be fairly interesting. While direct installation is most likely the quickest and least expensive implementation option, it comes with the most risks. And trying to save some time and a few bucks could end up costing you significantly in both areas if something goes wrong. Meanwhile parallel installation means running two systems at the same time and duplicating work. I can imagine that as an employee that would be a frustrating situation to have to, for example, enter information twice. The phased and single-location options are kind of a happy medium. I’m sure it all depends on the size and specifics of the project and organization, but I’m curious what the most popular, go-to installation strategy is.

After reading through Chapter 12 and our discussion in class, I think it’s easy to see that a lot of cloud computing is just the classic client/server architecture, but connected over the Internet, so the server in this case is in a data center somewhere rather than on site in the office. One section I found myself disagreeing with was the section on characteristics in order for something to be truly considered a cloud resource. The book stated that “the customer only rents a resource, with no knowledge or control over how it is provided or where it is located.” In my limited experience, there are many times that customers of major cloud services, such as AWS, specifically choose fairly defined and small regions where their cloud resources will be primarily hosted. With the contract with AWS, those organizations negotiated for primary resources to be located in a specific group of data centers in Northern Virginia and for backups also hosted by AWS to be stored in a data center in a different particular region based on the organization’s BCP and DRP. I’ve also seen instances where the contract dictates what other types of organizations may share the same physical hardware. For something to be labeled as being in the cloud, you don’t have to completely give up all of that control and be in the dark about what is going on. At least that’s my opinion.

One of the most important aspects of implementation, I think, is user acceptance testing. At the end of the day, systems are made to be used by users. They’re the ones who will be doing work or utilizing the system on a regular basis. When the users can actually get their hands on the system and start working with it, they can decide whether or not their requirements have been met. As the book describes, acceptance testing can be split into two types: alpha and beta. Alpha testing comes first and involves simulated data in a test environment. There are different types of tests that get run during this process, including stress tests, performance tests, recovery testing, and security testing. The goal is to identify bugs and the ways a system will react to different situations. Beta testing is where the actual users get involved. The system is put into their environment with real data and they get to try it out. As the book points out, it’s like a rehearsal. The system, training, documentation, etc. are all evaluated by real users.

I’m sure that user acceptance testing and actually getting users to accept a system can be a challenging, long process. But systems that skip it entirely are at great risk of a disastrous implementation. In those situations, the acceptance testing essentially comes when the system is put in place in production. It’s much harder to fix bugs and keep users happy then.

10_MACKEY_Uman Machine Interface

My thoughts after reading Chapters 10 and 11 are that forms and interfaces have a significant impact on how effective users think a system is and how well it performs as well. You can have a perfect database on the back end, but if it’s too hard to input information then it won’t be used to its potential. The success of forms, reports, interfaces, etc. really comes down to usability. I liked how the book discussed usability. First, it broke usability down into five factors: 1. consistency, 2. organization, 3. clarity, 4. format, and 5. flexibility. It also talked about measuring usability in terms of learnability, efficiency, error rate, memorability, and satisfaction and aesthetics.

It seems to me that multiple iterations of prototyping can be an effective way to develop forms, reports, and interfaces.

I was surprised, though, that accessibility wasn’t emphasized more within the chapters. I think you need to strongly consider how accessible your application or system is. For instance, having alt text for images and how easily it is to navigate with a screen reader. 

The “Modular Mayhem” section of the reading discussed modular programming and also the risks of code reuse. I found the most interesting discussion to be about the benefits and risks of code reuse. It can save time and resources. However, it can undermine the security of your program. Something that likely gets overlooked by slopping developers is that any internal libraries or APIs that you’re calling can be a concern. Internal libraries were often created before security was even thought about much so there may be many vulnerabilities. Developers can research vulnerabilities for any public libraries or APIs they will use. Code reviews can be done for internal code. The big idea is that you need to know and evaluate the entire attack surface for the system and application, which can be increased by libraries, modules, and APIs called from other sources. Those risks need to be mitigated.