Saturday 18 June 2011

Task 4

Software myths: beliefs about software and the process that is used to build it which may cause serious problem for developing team.
1.    Management myths:
Deploying an Electronic quality system can cost companies huge sums of money: the demand for electronic software management is always on the rise; Electronic quality makes jobs easier and saves time so fewer hours and less payments for workers, and shops these days offer affordable prices.
           
2.    Customer myths:
Customer Experience is Just a New Term for Customer Service: wrong customer service is too small which is included in customer experience, customer service is when customer have any inquiries or problems and asks developers for help, customer experience is how the software was helpful how easy or how hard was the use of the software etc.
3.    Practitioner Myth:
             Once we write the program and get it to work, our job is done: as soon we finish
             coding part we will find out that customers have more functions and different
             requirements that we need to prepare and add to the project .

Tuesday 14 June 2011

task 3

Task 2 Module 1


1.Method(s) best used to study the module: I would recomend reading after and before class just to learn the intro to this module.

2.Suggestion on topics that should be added or dropped from the module: Added maybe little about the history of software engineering would be intersted, drop no i think the information is all ready limited so no need to drop.
3.Suggestion on any other teaching-andlearning technique to be used during lecture and in-class activities: None.
5.All the lessons learned:
  • Software is: an specific task that when excuted should provide a desired results.
  • Documentation: documents that explains how the system works and how to use it. 
SOFTWARE MUST BE: adapted
                  enhanced  
                                        extended
                  re-architected

SE:The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance .

Wednesday 8 June 2011

Module 2

The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
This should not be confused with the Helical model of modern systems architecture that uses a dynamic programming (mathematical not software type programming!) approach in order to optimise the system's architecture before design decisions are made by coders that would cause problems.
History
The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software Development and Enhancement". This model was not the first model to discuss iterative development.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

The model

The spiral model combines the idea of iterative development (prototyping) with the systematic, controlled aspects of the waterfall model. It allows for incremental releases of the product, or incremental refinement through each time around the spiral. The spiral model also explicitly includes risk management within software development. Identifying major risks, both technical and managerial, and determining how to lessen the risk helps keep the software development process under control.
The spiral model is based on continuous refinement of key products for requirements definition and analysis, system and software design, and implementation (the code). At each iteration around the cycle, the products are extensions of an earlier product. This model uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations.
Documents are produced when they are required, and the content reflects the information necessary at that point in the process. All documents will not be created at the beginning of the process, nor all at the end (hopefully). Like the product they define, the documents are works in progress. The idea is to have a continuous stream of products produced and available for user review .
The spiral lifecycle model allows for elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design. This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early user involvement in the system development effort. For projects with heavy user interfacing, such as user application programs or instrument interface applications, such involvement is helpful .
Starting at the center, each turn around the spiral goes through several task regions :
  • Determine the objectives, alternatives, and constraints on the new iteration.
  • Evaluate alternatives and identify and resolve risk issues.
  • Develop and verify the product for this iteration.
  • Plan the next iteration.
Note that the requirements activity takes place in multiple sections and in multiple iterations, just as planning and risk analysis occur in multiple places. Final design, implementation, integration, and test occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using this method of development, some functionality can be delivered to the user faster than the waterfall method. The spiral method also helps manage risk and uncertainty by allowing multiple decision points and by explicitly admitting that all of anything cannot be known before the subsequent activity starts.
 Applications
The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military had adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003–2009), it had a two year iteration (spiral). The FCS should have resulted in three consecutive prototypes (one prototype per spiral—every two years). It was canceled in May 2009. The spiral model thus may suit small (up to $3 million) software applications and not a complicated ($3 billion) distributed, interoperable, system of systems.
Also it is reasonable to use the spiral model in projects where business goals are unstable but the architecture must be realized well enough to provide high loading and stress ability. For example, the Spiral Architecture Driven Development is the spiral based Software Development Life Cycle (SDLC) which shows one possible way how to reduce the risk of non-effective architecture with the help of a spiral model in conjunction with the best practices from other models.
Refrence: http://en.wikipedia.org/wiki/Spiral_model


Waterfall Model module 2

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.
The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and
theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.
The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.
Refrence: http://searchsoftwarequality.techtarget.com/definition/waterfall-model

Memebers Task 1

FULL NAME                          : Mohammed Mechail
ID                                             : GM086882
COURSE                                  : Graphic Multimedia